From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Garbage collector: is 800kb a good default? Date: Thu, 09 Apr 2020 15:31:43 -0400 Message-ID: References: <83h7xsoi03.fsf@gnu.org> <834ktso4t2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="19987"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: dim1212k@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 09 21:32:48 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMcuu-00057M-Ub for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Apr 2020 21:32:48 +0200 Original-Received: from localhost ([::1]:54580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMcuu-00007O-1l for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Apr 2020 15:32:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59421) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMctz-0007ta-Qo for emacs-devel@gnu.org; Thu, 09 Apr 2020 15:31:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMcty-00013N-8x for emacs-devel@gnu.org; Thu, 09 Apr 2020 15:31:51 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:42641) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jMctw-000128-Jf; Thu, 09 Apr 2020 15:31:48 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9857C810A2; Thu, 9 Apr 2020 15:31:46 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D964780D43; Thu, 9 Apr 2020 15:31:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1586460704; bh=VYOJUCqxMl/7pMmraMimKe5UVcas6oaFzGOMxe0vvGI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=iJnBkMCUI5/TmH9f7RBa+PjenGLJxQ60ilb91XB2x6fVqKobv0FqxTRebub0D0R7T ybxiM3Zui+yrCYF306wH9AXTKL/2bGdyR9YqlyrPFm2gsEpiDGMOS6qbtqkbC1Piws UHxbfBrD8eDH2ruGcXTZmkGL7FktOKG6UxtOoydudzatS2E3u5CYBzoxUZGs/cB9Ev vZloRWQU8Hci9bQFRpT+70R3CJRU5PjfAJn54qxWOWxTFBLRc116FIwesVZHhOL2OY rPaKa5RqCUETdxG/Wg7Bd82AoxbN7iNdjqH+SISiC+c+bdIqwU/UjssPMjodl7C1kO sQPjS+Y8ei60Q== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8FED41204E9; Thu, 9 Apr 2020 15:31:44 -0400 (EDT) In-Reply-To: <834ktso4t2.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Apr 2020 22:08:25 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246729 Archived-At: > The difference is that when an idle timer runs a long uninterruptible > calculation, the user thinks Emacs is idle, so having a character > appear, or Emacs respond to a command with a prompt, after a > significant delay makes a very bad UX. By contrast, when a command is > running, the user will normally know that Emacs isn't idle, so a > delayed response will be less of a surprise. No, that's not what I was saying. What I was saying is that in the"idle GC case" the events are as follows: 1- 100%-N% of the GC runs while idle. 2- the user hits a key 3- the remaining N% of the GC runs. 4- the command runs whereas in the non-idle GC what happens is: 1- the user hits a key 2- the command starts 3- the GC gets run 4- the command continues and finiches To the user, the result is pretty much the same: in both cases Emacs took "time to run the command + time to GC" before responding. In the idle-GC the time should be arguably a bit *shorter* because only N% of the GC is counted towards to total delay before sending the response. >> > Also, we already try running GC each time Emacs becomes idle. >> Do we? I thought so as well, but I couldn't see any evidence of it in >> the code. > It's in keyboard.c, right after we auto-save when enough idle time has > passed: > > /* If there is still no input available, ask for GC. */ > if (!detect_input_pending_run_timers (0)) > maybe_gc (); But that's not the same: this "maybe_gc" rarely triggers because it uses the same thresholds as normal code evaluation, so if the GC was not triggered while running the last command it usually won't trigger here either. The fundamental idea of idle-GC is to use a *lower* threshold while idle, so as to increase the probability that the GC happens on that occasion rather than one of the other "maybe_gc" checks. Stefan