From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitrii Korobeinikov Newsgroups: gmane.emacs.devel Subject: Garbage collector: is 800kb a good default? Date: Thu, 9 Apr 2020 17:59:04 +0600 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="112876"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 09 13:59:51 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 1jMVqZ-000TGa-Dn for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Apr 2020 13:59:51 +0200 Original-Received: from localhost ([::1]:48102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMVqY-00064j-GH for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Apr 2020 07:59:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47514) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMVq3-0005f7-Bm for emacs-devel@gnu.org; Thu, 09 Apr 2020 07:59:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMVq2-0006Jq-53 for emacs-devel@gnu.org; Thu, 09 Apr 2020 07:59:19 -0400 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:39923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jMVq1-0006JU-VJ for emacs-devel@gnu.org; Thu, 09 Apr 2020 07:59:18 -0400 Original-Received: by mail-wm1-x333.google.com with SMTP id y24so3910164wma.4 for ; Thu, 09 Apr 2020 04:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Hpu1a5BBJCeknx/u9b9Wo8ig3W8kOTmDhpzhH5i03dI=; b=kUcJOdww/vEZJ0GQFgBStiQpjpNmCfSALJyPF6SLTLeHtszp3PE48YjAPGCUWyCVXy qwWdlWPGgKx3WPV3SpQsg47kGOFkkEsl2IGCcIEbFpAshSXvP0JncHo/m/MBmbZMvY1x LPRgli5vsnVKPfr2PL4DNyPmcxFkljVZz9KcVnTMrENKd8TfvRFp4JoeNgAm/0pIKip7 yjfvG4eAGTa9qwFmoXsL7E60AmRO3pbybviYUAj1x9tFMnLSEIaMBSiUtOK2o8NT5hK4 RpK+e6U7UTSMYAWYbqP5xpqS2QUkXzkyPj/rQtTiFxZX5RFWNSzWwb0ntf/hrkglbMQJ Jm5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hpu1a5BBJCeknx/u9b9Wo8ig3W8kOTmDhpzhH5i03dI=; b=Z++9fSYp9jjKCfKluSPe4/zoTN1pVglADYVYkoiKVAiDSfrcRxxau9gCCFVG8nViGy wzFEnMcyzqKRV1x1+zyWZU68upEaFskxH2ElRhDuGmrDW+mZPZu3fkrKLIkmt4XFiodT 9289LZV3i6TTS7NpF4D8dqzpGkefM+uSQKRlLOQGe50cztk5iOX2KbtMHpWN4AY2D/3t w3px6LP/9usO+m3O4nbhfenX5HzGJpxvyX4iHzJZu59YPk2zFu3Ve4R1oEAfpYx7G4P6 i+sOGJTnXy7kald4N9jbU+tjdnxxM4FuLyrRRgDpR6LC+f/n0G6+Y4fgt32paN9PTUH2 vFMQ== X-Gm-Message-State: AGi0PuZaEIpRFk1XY2Vpg4ZzkRbXJ6+KR0/J7T3mHpASzm6/sUiIxJ0N BhEkc2mJXHXiVazXrBwes3O66SATIHHOE695vFcBa6cn X-Google-Smtp-Source: APiQypJkOJvoWkw9F9ZOjF4C4TMEOt4pFFXzim7VV9b68i1Bgj5zLM262l/m2V8mss8BzMevDJmGbO8e0H0SHa5ewVg= X-Received: by 2002:a1c:e187:: with SMTP id y129mr10361657wmg.133.1586433556222; Thu, 09 Apr 2020 04:59:16 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::333 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:246704 Archived-At: Hi all, So, I was debugging scrolling, it felt evidently clunky for large files for me. Font lock is the elephant in the room, but I decided to profile my custom half-screen scroll functions anyway and was quite surprised to find that GC was gobbling 38% of the CPU time. That didn't have anything to do with my functions, the default full page scroll has it the same. That lead to some experimenation with gc-cons-threshold. Higher values of this variable resulted in much less frequent freezes/pauses while scrolling [1]. Setting garbage-collection-messages to t and gs-cons-threshold to 80MB, I figured I can scroll a voluminous sheet of 7k lines before gc has to do its job. With the default 0.8 it's every 2-3 pagescrolls. That's a big difference. Of course, raising the threshold significantly higher on its own is not a very good idea. But if paired with an idle timer like suggested here [2], then it all starts looking like a decent combination: (setq gc-cons-threshold mem) (run-with-idle-timer 2 t 'garbage-collect) It would be good to find a threshold which the user barely has a chance of reaching unless running a long uninterrupted task. And, by the way, in this latter case, it is better to have a higher threshold too due to the increase in speed, like with startup [3]. Setting the threshold just a bit higher than the current default wouldn't help much but may actually be worse as the pauses would be longer, but about as frequent. Too high a value would create very long freezes for uninterrupted tasks. But there should be a good middle ground. So, as far as I can see, defaulting to a higher threshold with an idle timer could yield better user experience with practically no significant tradeoffs. Is there something I might be missing here? Best, DK [1] This is evident in vanilla emacs if you pay attention, but it's much more so for me w/ my the bloated config. I haven't yet found the culprit. [2] https://emacs.stackexchange.com/questions/34342/is-there-any-downside-to-setting-gc-cons-threshold-very-high-and-collecting-ga [3] | threshold (MB) | startup time (s) | |----------------+------------------| | 0.8 | 9.14 | | 2 | 8.77 | | 5 | 7.54 | | 20 | 6.88 | | 50 | 6.65 | | 80 | 6.73 | | 100 | 6.17 |