diff options
Diffstat (limited to '2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt')
| -rw-r--r-- | 2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt | 2052 |
1 files changed, 1492 insertions, 560 deletions
diff --git a/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt b/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt index c1bea8de..d1e2a5f6 100644 --- a/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt +++ b/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt @@ -1,848 +1,1780 @@ -WEBVTT +WEBVTT captioned by sachac -00:00.000 --> 00:06.480 -Hello everyone, my name is Igor Achinko and you may know me from Org Mailing List. +NOTE Introduction -00:07.440 --> 00:11.760 -However, today I'm not going to talk about Org Mode. Today I'm going to talk about +00:00:00.000 --> 00:00:04.639 +Hello everyone, my name is Ihor Radchenko, -00:11.760 --> 00:16.800 -Emacs performance and how it's affected by its memory management code. +00:00:04.640 --> 00:00:07.599 +and you may know me from Org Mailing List. -00:18.880 --> 00:24.720 -First, I will introduce the basic concepts of Emacs memory management and what garbage +00:00:07.600 --> 00:00:09.799 +However, today I'm not going to talk about Org Mode. -00:24.720 --> 00:32.320 -collection is. Then I will show you user statistics collected from volunteer users +00:00:09.800 --> 00:00:11.919 +Today I'm going to talk about -00:32.320 --> 00:42.080 -over the last half year and I will end with some guidelines on how to tweak Emacs garbage +00:00:11.920 --> 00:00:14.959 +Emacs performance and how it's affected -00:42.080 --> 00:48.640 -collection customizations to optimize Emacs performance and when it's necessary or not +00:00:14.960 --> 00:00:19.039 +by its memory management code. -00:49.120 --> 00:56.560 -to do. Let's begin. What is garbage collection? To understand what is garbage collection we need +00:00:19.040 --> 00:00:21.639 +First, I will introduce the basic concepts -00:56.560 --> 01:01.920 -to realize that anything you do in Emacs is some kind of command and any command is most likely +00:00:21.640 --> 00:00:26.439 +of Emacs memory management and what garbage collection is. -01:01.920 --> 01:07.280 -running some Elisp code and every time you run Elisp code you most likely need to locate certain +00:00:26.440 --> 00:00:30.559 +Then I will show you user statistics -01:07.280 --> 01:14.160 -memory in RAM and some of this memory is retained for a long time and some of this memory is +00:00:30.560 --> 00:00:34.959 +collected from volunteer users over the last half year -01:14.160 --> 01:20.320 -transient. Of course, Emacs has to clear this transient memory from time to time to not occupy +00:00:34.960 --> 00:00:39.319 +and I will end with some guidelines -01:20.320 --> 01:27.200 -all the possible RAM in the computer. In this small example we have one global variable +00:00:39.320 --> 00:00:44.719 +on how to tweak Emacs garbage collection customizations -01:28.480 --> 01:35.600 -that is assigned a value but when assigning the value we first allocate a temporary variable +00:00:44.720 --> 00:00:47.479 +to optimize Emacs performance -01:35.600 --> 01:41.360 -and then a temporary list and only retain some part of this list in this global variable. +00:00:47.480 --> 00:00:51.079 +and when it's necessary or not to do. -01:42.240 --> 01:51.920 -In terms of memory graph we can represent this as two variable slots, one transient, one permanent +NOTE About garbage collection in Emacs -01:52.480 --> 02:01.680 -and then a list of three concerns and part of which is retained as a global variable but part +00:00:51.080 --> 00:00:54.519 +Let's begin. What is garbage collection? -02:01.680 --> 02:07.280 -of it which is a temporary variable symbol and the first term of the list is not used and it +00:00:54.520 --> 00:00:56.519 +To understand what is garbage collection, -02:07.840 --> 02:15.040 -might be cleared at some point. So that's what Emacs does. Every now and then Emacs goes through +00:00:56.520 --> 00:00:59.039 +we need to realize that anything you do in Emacs -02:15.040 --> 02:20.320 -all the memory and identify which part of the memory are not used and then clear them so that +00:00:59.040 --> 00:01:02.119 +is some kind of command. Any command is most likely -02:20.320 --> 02:27.760 -it can free up the RAM. This process is called garbage collection and Emacs uses a very simple +00:01:02.120 --> 00:01:05.839 +running some Elisp code. Every time you run Elisp code, -02:27.760 --> 02:33.440 -and old algorithm which is called mark and sweep. So during this mark and sweep process +00:01:05.840 --> 00:01:09.239 +you most likely need to locate certain memory in RAM. -02:33.440 --> 02:40.880 -is basically two stages. First Emacs scans all the memory that is allocated and then identify +00:01:09.240 --> 00:01:12.879 +Some of this memory is retained for a long time -02:40.880 --> 02:46.320 -which memory is still in use which is linked to some variables for example and which memory is +00:01:12.880 --> 00:01:15.559 +and some of this memory is transient. -02:46.320 --> 02:51.600 -not used anymore even though it was allocated in the past and the second stage is clear that +00:01:15.560 --> 00:01:19.119 +Of course, Emacs has to clear this transient memory -02:51.600 --> 02:56.240 -whatever a memory is not that is not allocated. During the process +00:01:19.120 --> 00:01:21.439 +from time to time, to not occupy all the possible RAM -02:56.880 --> 03:03.920 -Emacs cannot do anything now. So basically every time Emacs scans the memory it freezes up and +00:01:21.440 --> 00:01:21.447 +in the computer. In this small example, -03:03.920 --> 03:09.840 -doesn't respond to anything and if it takes too much time so that users can notice it then of +00:01:21.448 --> 00:01:28.639 +we have one global variable -03:09.840 --> 03:18.160 -course Emacs is not responsive at all and if this garbage collection is triggered too frequently +00:01:28.640 --> 00:01:31.279 +that is assigned a value, -03:18.160 --> 03:23.760 -then it's not just not responsive every now and then it's also not responsive all the time almost +00:01:31.280 --> 00:01:33.079 +but when assigning the value, -03:24.000 --> 03:29.840 -all the time so it cannot even normally type or stuff or do some normal commands. +00:01:33.080 --> 00:01:35.679 +we first allocate a temporary variable -03:32.320 --> 03:40.080 -This mark and sweep algorithm is taking longer the more memory Emacs uses. So basically +00:01:35.680 --> 00:01:37.119 +and then a temporary list -03:40.080 --> 03:46.480 -the more buffers you open, the more packages you load, the more complex commands you run, +00:01:37.120 --> 00:01:40.079 +and only retain some part of this list -03:46.480 --> 03:55.840 -the more memory is used and basically the longer Emacs takes to perform a single garbage collection. +00:01:40.080 --> 00:01:42.079 +in this global variable. -04:00.560 --> 04:07.280 -Of course Emacs being Emacs and this garbage collection can be tweaked. In particular +00:01:42.080 --> 00:01:44.799 +In terms of memory graph -04:07.280 --> 04:12.960 -users can tweak how frequently Emacs does garbage collection using two basic variables +00:01:44.800 --> 00:01:50.359 +we can represent this as two variable slots, -04:12.960 --> 04:19.840 -GCConsThreshold and GCConsPercentage. GCConsThreshold is the raw number of kilobytes +00:01:50.360 --> 00:01:53.159 +one transient, one permanent, -04:21.440 --> 04:27.200 -Emacs needs to allocate before triggering another garbage collection and the GCConsPercentage +00:01:53.160 --> 00:01:56.199 +and then a list of three cons cells, -04:27.200 --> 04:31.680 -is similar but it's defined in terms of fraction of already allocated memory. +00:01:56.200 --> 00:02:01.959 +part of which is retained as a global variable -04:33.840 --> 04:41.840 -If you follow various Emacs forums you may be familiar with people complaining about +00:02:01.960 --> 00:02:04.999 +but part of it which is a temporary variable symbol. -04:41.840 --> 04:47.760 -garbage collection and there are many many suggestions about what to do with it. +00:02:05.000 --> 00:02:07.679 +The first term of the list is not used -04:50.320 --> 04:52.640 -Most frequently you see GCConsThreshold +00:02:07.680 --> 00:02:09.759 +and it might be cleared at some point. -04:54.640 --> 05:01.280 -recommended to be increased and a number of pre-packaged Emacs distributions like +NOTE Garbage collection in Emacs -05:01.280 --> 05:07.280 -DoMeEmacs do increase it or like I have seen suggestions which are actually horrible to +00:02:09.760 --> 00:02:12.239 +So that's what Emacs does. -05:07.280 --> 05:11.120 -disable garbage collection temporarily or for a long time. +00:02:12.240 --> 00:02:15.919 +Every now and then, Emacs goes through all the memory -05:14.240 --> 05:19.600 -Which is nice you can see it quite frequently which indicates there might be some problem. +00:02:15.920 --> 00:02:19.119 +and identifies which part of the memory are not used -05:19.600 --> 05:26.320 -However every time like one user poses about this problem it's just one data point and it doesn't +00:02:19.120 --> 00:02:23.759 +and then clear them so that it can free up the RAM. -05:26.320 --> 05:30.000 -mean that everyone actually suffers from it. It doesn't mean that everyone should do it. +00:02:23.760 --> 00:02:25.919 +This process is called garbage collection -05:30.720 --> 05:37.680 -So in order to understand if this garbage collection is really a problem which is a +00:02:25.920 --> 00:02:28.919 +and Emacs uses a very simple and old algorithm -05:37.680 --> 05:48.000 -common problem we do need some kind of statistics and only using the actual statistics we can +00:02:28.920 --> 00:02:30.559 +which is called Mark & Sweep. -05:48.000 --> 05:54.880 -understand if it should be recommended for everyone to tweak the defaults or like whether +00:02:30.560 --> 00:02:33.759 +So doing this mark and sweep process -05:54.880 --> 06:00.000 -it should be recommended for certain users or maybe it should be asked Emacs devs to do +00:02:33.760 --> 00:02:34.879 +is basically two stages. -06:00.000 --> 06:08.800 -something about the defaults. And what I did some time ago is exactly this. I tried to collect the +00:02:34.880 --> 00:02:40.039 +First, Emacs scans all the memory that is allocated -06:08.800 --> 06:18.000 -user statistics. So I wrote a small package on Elp and some users installed this package and +00:02:40.040 --> 00:02:42.759 +and then identifies which memory is still in use -06:18.000 --> 06:24.080 -then reported back these statistics of the garbage collection for their particular use. +00:02:42.760 --> 00:02:45.519 +which is linked to some variables, for example, -06:25.360 --> 06:33.840 -By now we have obtained 129 user submissions with over 1 million GC records in there. +00:02:45.520 --> 00:02:47.599 +and which memory is not used anymore -06:35.760 --> 06:42.320 -So like some of these submissions used default GC settings without any customizations. +00:02:47.600 --> 00:02:49.559 +even though it was allocated in the past. -06:42.320 --> 06:47.040 -Some used increased GC cost threshold and GC cost percentage. +00:02:49.560 --> 00:02:52.999 +The second stage [??] whenever a memory is not, -06:48.880 --> 06:56.640 -So using this data we can try to draw some reliable conclusions on what should be done +00:02:53.000 --> 00:02:59.319 +that is not allocated. During the process -06:56.640 --> 07:02.480 -and whether should anything be done about garbage collection on Emacs dev level or at least on user +00:02:59.320 --> 00:03:00.759 +Emacs cannot do anything now. -07:02.480 --> 07:08.240 -level. Of course we need to keep in mind that there's some kind of bias because it's more +00:03:00.760 --> 00:03:04.159 +So basically, every time Emacs scans the memory, -07:08.240 --> 07:13.680 -likely that users already have problems with GC or they think they have problems with GC will report +00:03:04.160 --> 00:03:07.199 +it freezes up and doesn't respond to anything, -07:14.480 --> 07:20.240 -and submit the data. But anyway having s statistics is much more useful than just +00:03:07.200 --> 00:03:10.959 +and if it takes too much time so that users can notice it, -07:20.240 --> 07:28.240 -having anecdotal evidences from one or other reddit posts. And just one thing I will do +00:03:10.960 --> 00:03:13.399 +then of course Emacs is not responsive at all, -07:28.880 --> 07:33.280 -during the rest of my presentation is that for all the statistics I will normalize +00:03:13.400 --> 00:03:19.439 +and if this garbage collection is triggered too frequently, -07:33.520 --> 07:41.440 -user data so that every user contributes equally. For example if one user submits like 100 hours +00:03:19.440 --> 00:03:22.399 +then it's not just not responsive every now and then. -07:41.440 --> 07:46.640 -Emacs uptime statistics and other users submit one hour Emacs uptime then I will +00:03:22.400 --> 00:03:24.679 +It's also not responsive all the time, -07:47.200 --> 07:49.520 -anyway make it so that they contribute equally. +00:03:24.680 --> 00:03:26.079 +almost all the time, -07:53.280 --> 07:59.280 -Let's start from one of the most obvious things we can look into is which is the time it takes +00:03:26.080 --> 00:03:27.679 +so it cannot even normally type or stuff -07:59.360 --> 08:05.520 -for garbage collection to single garbage collection process. Here you see +00:03:27.680 --> 00:03:32.439 +or do some normal commands. -08:08.240 --> 08:16.240 -frequency distribution of GC duration for all the 129 users we got and +00:03:32.440 --> 00:03:36.719 +This mark and sweep algorithm is taking longer -08:17.600 --> 08:26.800 -you can see that most of the garbage collections are done quite quickly in less than 0.1 second +00:03:36.720 --> 00:03:40.199 +the more memory Emacs uses. So basically, -08:27.440 --> 08:33.680 -and less than 0.1 second is usually just not noticeable. So even though there is garbage +00:03:40.200 --> 00:03:44.439 +the more buffers you open, the more packages you load, -08:33.680 --> 08:43.200 -collection it will not interrupt the work in Emacs. However there is a fraction of users who +00:03:44.440 --> 00:03:48.319 +the more complex commands you run, the more memory is used, -08:43.920 --> 08:49.680 -experience garbage collection it takes like 0.2, 0.3 or even half a second which will be quite +00:03:48.320 --> 00:03:52.279 +and basically, the longer Emacs takes -08:49.680 --> 08:58.800 -noticeable. For the purposes of this study I will consider that anything that is less than 0.1 +00:03:52.280 --> 00:03:57.919 +to perform a single garbage collection. -08:58.800 --> 09:06.000 -second which is insignificant so like you will not notice it and it's like obviously all the Emacs +00:03:57.920 --> 00:04:02.279 +Of course, Emacs being Emacs -09:06.000 --> 09:13.600 -usage will be just normal. But if it's more than 0.1 or 0.2 seconds then it will be very noticeable +00:04:02.280 --> 00:04:06.039 +this garbage collection can be tweaked. -09:13.600 --> 09:20.800 -and you will see that Emacs hang for a little while or not so little while. In terms of numbers +00:04:06.040 --> 00:04:08.279 +In particular users can tweak -09:21.360 --> 09:28.000 -it's better to plot the statistics not as a distribution but as a cumulative distribution. +00:04:08.280 --> 00:04:10.639 +how frequently Emacs does garbage collection -09:29.040 --> 09:34.080 -So like at every point of this graph you'll see like for example here 0.4 seconds +00:04:10.640 --> 00:04:13.879 +using two basic variables: `gc-cons-threshold` -09:34.480 --> 09:49.040 -you have this percent of like almost 90% of users have no more than 0.4 gc duration. So like +00:04:13.880 --> 00:04:15.519 +and `gc-cons-percentage`. -09:49.040 --> 09:55.760 -we can look here if we take one gc critical gc duration which is 0.1 second +00:04:15.520 --> 00:04:21.599 +`gc-cons-threshold` is the raw number of kilobytes -09:55.840 --> 10:02.400 -0.1 second and look at how many users have it so we have 56% which is like +00:04:21.600 --> 00:04:22.479 +Emacs needs to allocate -10:03.600 --> 10:12.880 -44% users have less than 0.1 second gc duration and the rest 56% have more than 0.1 second. +00:04:22.480 --> 00:04:25.959 +before triggering another garbage collection, -10:13.600 --> 10:20.720 -So you can see like more than half of users actually have noticeable gc delay so the +00:04:25.960 --> 00:04:27.799 +and the `gc-cons-percentage` is similar, -10:20.720 --> 10:27.040 -Emacs freezes for some noticeable time and a quarter of users actually have very noticeable +00:04:27.800 --> 00:04:30.399 +but it's defined in terms of fraction -10:27.040 --> 10:36.640 -so like Emacs freezes such that you see an actual delay that Emacs actually has +00:04:30.400 --> 00:04:34.759 +of already-allocated memory. -10:37.760 --> 10:47.600 -which is quite significant and important point. But apart from the duration of each individual gc +00:04:34.760 --> 00:04:38.239 +If you follow various Emacs forums, -10:47.600 --> 10:52.640 -it is important to see how frequent it is because even if you do notice a delay +00:04:38.240 --> 00:04:41.959 +you may be familiar with people complaining about -10:53.440 --> 10:59.120 -even a few seconds delay it doesn't matter if it happens once during the whole Emacs session. +00:04:41.960 --> 00:04:46.479 +garbage collection. There are many many suggestions -11:01.360 --> 11:10.720 -So if you look into frequency distribution again here I plot time between +00:04:46.480 --> 00:04:48.039 +about what to do with it. -11:11.680 --> 11:17.760 -subsequent garbage collections versus how frequent it is and we have very clear trend that +00:04:48.040 --> 00:04:54.079 +Most frequently, you see `gc-cons-threshold` -11:18.560 --> 11:24.560 -most of the garbage collections are quite frequent like we talk about every few seconds a few tens +00:04:54.080 --> 00:04:56.879 +recommended to be increased, -11:24.560 --> 11:32.560 -of seconds. There's a few outliers which are at very round numbers like 60 seconds, 120 seconds, +00:04:56.880 --> 00:05:01.439 +and a number of pre-packaged Emacs distributions -11:32.560 --> 11:40.640 -300 seconds. These are usually timers so like you have something running on timer and then it +00:05:01.440 --> 00:05:04.319 +like Doom Emacs do increase it. -11:41.440 --> 11:48.000 -is complex command and it triggers garbage collection but it's not the majority. +00:05:04.320 --> 00:05:07.279 +I have seen suggestions which are actually horrible -11:49.280 --> 11:54.000 -Again to run the numbers it's better to look into cumulative distribution and see that +00:05:07.280 --> 00:05:10.479 +to disable garbage collection temporarily -11:54.000 --> 11:58.160 -50% of garbage collections are basically less than 10 seconds apart. +00:05:10.480 --> 00:05:14.359 +or for a long time. -12:00.000 --> 12:07.920 -And we can combine it with previous data and we look into whatever garbage collection takes +00:05:14.360 --> 00:05:17.519 +Which is nice... You can see it quite frequently, -12:07.920 --> 12:12.960 -less than 10 seconds from each other and also takes more than say 0.1 seconds. +00:05:17.520 --> 00:05:19.399 +which indicates there might be some problem. -12:13.680 --> 12:20.800 -So and then we see that one quarter of all garbage collections are just noticeable and also frequent +00:05:19.400 --> 00:05:23.959 +However, every time one user poses about this problem, -12:21.760 --> 12:27.840 -and 9% are not like more than 0.2% very noticeable and also frequent. So basically +00:05:23.960 --> 00:05:26.879 +it's just one data point and it doesn't mean -12:27.840 --> 12:34.480 -it constitutes Emacs freezing. So 9% of all the garbage collection Emacs freezing. Of course +00:05:26.880 --> 00:05:28.879 +that everyone actually suffers from it. -12:35.360 --> 12:42.960 -if you remember there is a bias but 9% is quite significant number. So garbage collection can +00:05:28.880 --> 00:05:33.719 +It doesn't mean that everyone should do it. -12:42.960 --> 12:47.280 -really slow down things not for everyone but for significant fraction of users. +00:05:33.720 --> 00:05:35.919 +So in order to understand if this garbage collection -12:49.440 --> 12:57.440 -Another thing I'd like to look into is what I call agglomerated GCs. What I mean by agglomerated +00:05:35.920 --> 00:05:39.959 +is really a problem which is a common problem -12:57.440 --> 13:02.720 -is when you have one garbage collection and then another garbage immediately after it. So +00:05:39.960 --> 00:05:44.919 +we do need some kind of statistics -13:03.680 --> 13:09.840 -in terms of numbers I took every subsequent garbage collection which is either immediately +00:05:44.920 --> 00:05:46.919 +and only using the actual statistics -13:09.840 --> 13:16.000 -after or no more than one second after each. So from point of view of users is like +00:05:46.920 --> 00:05:52.759 +we can understand if it should be recommended for everyone -13:16.960 --> 13:22.880 -multiple garbage collection they add up together into one giant garbage collection. +00:05:52.760 --> 00:05:54.999 +to tweak the defaults or like whether -13:23.440 --> 13:29.440 -And if you look into numbers of how many agglomerated garbage collections there are +00:05:55.000 --> 00:05:57.159 +it should be recommended for certain users -13:29.440 --> 13:35.360 -you can see even numbers over 100. So 100 garbage collection going one after another. +00:05:57.160 --> 00:05:59.479 +or maybe it should be asked Emacs devs -13:36.720 --> 13:42.560 -Even if you think about each garbage collection taking 0.1 second we look into 100 of them +00:05:59.480 --> 00:06:01.559 +to do something about the defaults. -13:43.280 --> 13:50.480 -it's total 10 seconds. It's like Emacs hanging forever or like a significant number is also 10. +00:06:01.560 --> 00:06:07.959 +And what I did some time ago is exactly this. -13:50.480 --> 13:58.160 -So again this would be very annoying to meet such thing. How frequently does it happen? Again we +00:06:07.960 --> 00:06:09.959 +I tried to collect the user statistics. -13:58.160 --> 14:04.400 -can plot cumulative distribution and we see that 20 percent like 19 percent of all the garbage +00:06:09.960 --> 00:06:14.519 +So I wrote a small package on Elp -14:04.400 --> 14:13.680 -collection are at least two together and 8 percent like more than 10. So like you think about oh +00:06:14.520 --> 00:06:18.159 +and some users installed this package -14:13.680 --> 14:17.840 -each garbage collection is not taking much time but when you have 10 of them yeah that becomes a +00:06:18.160 --> 00:06:22.119 +and then reported back these statistics -14:17.840 --> 14:32.560 -problem. Another thing is to answer a question that some people complain about is that +00:06:22.120 --> 00:06:24.279 +of the garbage collection for their particular use. -14:33.680 --> 14:42.320 -longer you use Emacs the slower Emacs become. Of course it may be caused by garbage collection and +00:06:24.280 --> 00:06:30.799 +By now we have obtained 129 user submissions -14:42.720 --> 14:50.000 -I wanted to look into how garbage collection time and other statistics, other parameters +00:06:30.800 --> 00:06:34.039 +with over 1 million GC records in there. -14:50.880 --> 14:58.880 -are evolving over time. And what I can see here is a cumulative distribution of GC duration +00:06:34.040 --> 00:06:38.119 +So like some of these submissions -14:59.680 --> 15:04.720 -for like first 10 minutes of Emacs uptime first 100 minutes first 1000 minutes. +00:06:38.120 --> 00:06:43.159 +used default GC settings without any customizations. -15:05.520 --> 15:13.840 -And if you look closer then you see that each individual garbage collection on average +00:06:43.160 --> 00:06:46.039 +Some used increased GC cost threshold -15:15.440 --> 15:24.000 -takes longer as you use Emacs longer. However this longer is not much it's like maybe 10 percent +00:06:46.040 --> 00:06:47.799 +and GC cost percentage. -15:24.000 --> 15:33.040 -like basically garbage collection gets like slow Emacs down more as you use Emacs more +00:06:47.800 --> 00:06:53.319 +So using this data we can try to draw -15:33.680 --> 15:40.320 -but not much. So basically if you do you see Emacs being slower and slower over time +00:06:53.320 --> 00:06:56.879 +some reliable conclusions on what should be done -15:40.960 --> 15:46.960 -it's probably not really garbage collection because it doesn't change too much. And if you +00:06:56.880 --> 00:06:59.919 +and whether should anything be done about garbage collection -15:46.960 --> 15:52.720 -look into time between individual garbage collections and you see that the time actually +00:06:59.920 --> 00:07:02.639 +on Emacs dev level or at least on user level. -15:52.720 --> 15:58.880 -increases as you use Emacs longer which makes sense because initially like first few minutes +00:07:02.640 --> 00:07:05.639 +Of course we need to keep in mind -15:58.880 --> 16:04.720 -you have all kind of packages loading like all the port loading and then later everything is +00:07:05.640 --> 00:07:07.279 +that there's some kind of bias -16:04.720 --> 16:12.560 -loaded and things become more stable. So the conclusion on this part is that +00:07:07.280 --> 00:07:08.999 +because it's more likely -16:13.520 --> 16:18.480 -if Emacs becomes slower in a long session it's probably not caused by garbage collection. +00:07:09.000 --> 00:07:11.719 +that users already have problems with GC -16:20.320 --> 16:27.760 -And one word of warning of course is that it's all nice and all when I present the statistics +00:07:11.720 --> 00:07:13.239 +or they think they have problems with GC -16:27.760 --> 16:32.800 -but it's only an average and if you are an actual user like here is one example +00:07:13.240 --> 00:07:15.919 +will report and submit the data. -16:34.080 --> 16:39.920 -which shows a total garbage collection time like accumulated together over Emacs uptime +00:07:15.920 --> 00:07:19.999 +But anyway having s statistics is much more useful -16:40.880 --> 16:45.360 -and you see different lines which correspond to different sessions of one user +00:07:20.000 --> 00:07:22.079 +than just having anecdotal evidences -16:46.800 --> 16:51.360 -and you see they are wildly different like one time there is almost no garbage collection +00:07:22.080 --> 00:07:25.519 +from one or other reddit posts. -16:52.240 --> 16:57.840 -another time you see garbage collection because probably Emacs is used more early or like +00:07:25.520 --> 00:07:28.759 +And just one thing I will do -16:57.840 --> 17:04.560 -different pattern of usage and even during a single Emacs session you see a different slope +00:07:28.760 --> 00:07:30.879 +during the rest of my presentation -17:04.560 --> 17:10.560 -of this curve which means that sometimes garbage collection is infrequent and sometimes it's much +00:07:30.880 --> 00:07:32.839 +is that for all the statistics -17:10.560 --> 17:16.000 -more frequent so it's probably much more noticeable one time and less noticeable other time. +00:07:32.840 --> 00:07:35.679 +I will normalize user data -17:16.000 --> 17:23.360 -So if you think about these statistics of course they only represent an average usage +00:07:35.680 --> 00:07:37.879 +so that every user contributes equally. -17:23.360 --> 17:26.240 +00:07:37.880 --> 00:07:40.279 +For example if one user submits like + +00:07:40.280 --> 00:07:43.119 +100 hours Emacs uptime statistics + +00:07:43.120 --> 00:07:46.279 +and other users submit one hour Emacs uptime + +00:07:46.280 --> 00:07:52.879 +then I will anyway make it so that they contribute equally. + +00:07:52.880 --> 00:07:56.359 +Let's start from one of the most obvious things + +00:07:56.360 --> 00:07:57.679 +we can look into is + +00:07:57.680 --> 00:08:00.599 +which is the time it takes for garbage collection + +00:08:00.600 --> 00:08:05.879 +to single garbage collection process. + +00:08:05.880 --> 00:08:11.839 +Here you see frequency distribution of GC duration + +00:08:11.840 --> 00:08:14.999 +for all the 129 users we got + +00:08:15.000 --> 00:08:22.279 +and you can see that most of the garbage collections + +00:08:22.280 --> 00:08:26.999 +are done quite quickly in less than 0.1 second + +00:08:27.000 --> 00:08:32.199 +and less than 0.1 second is usually just not noticeable. + +00:08:32.200 --> 00:08:34.519 +So even though there is garbage collection + +00:08:34.520 --> 00:08:39.639 +it will not interrupt the work in Emacs. + +00:08:39.640 --> 00:08:43.279 +However there is a fraction of users + +00:08:43.280 --> 00:08:45.279 +who experience garbage collection + +00:08:45.280 --> 00:08:48.399 +it takes like 0.2, 0.3 or even half a second + +00:08:48.400 --> 00:08:50.399 +which will be quite noticeable. + +00:08:50.400 --> 00:08:55.279 +For the purposes of this study + +00:08:55.280 --> 00:08:59.399 +I will consider that anything that is less than 0.1 second + +00:08:59.400 --> 00:09:02.639 +which is insignificant so like you will not notice it + +00:09:02.640 --> 00:09:04.159 +and it's like obviously + +00:09:04.160 --> 00:09:07.479 +all the Emacs usage will be just normal. + +00:09:07.480 --> 00:09:11.639 +But if it's more than 0.1 or 0.2 seconds + +00:09:11.640 --> 00:09:13.799 +then it will be very noticeable + +00:09:13.800 --> 00:09:16.079 +and you will see that Emacs hang for a little while + +00:09:16.080 --> 00:09:21.319 +or not so little while. In terms of numbers + +00:09:21.320 --> 00:09:26.239 +it's better to plot the statistics not as a distribution + +00:09:26.240 --> 00:09:28.199 +but as a cumulative distribution. + +00:09:28.200 --> 00:09:31.559 +So like at every point of this graph + +00:09:31.560 --> 00:09:37.159 +you'll see like for example here 0.4 seconds + +00:09:37.160 --> 00:09:42.279 +you have this percent of like almost 90% of users + +00:09:42.280 --> 00:09:49.279 +have no more than 0.4 gc duration. + +00:09:49.280 --> 00:09:53.239 +So like we can look here if we take one + +00:09:53.240 --> 00:09:56.879 +gc critical gc duration which is 0.1 second + +00:09:56.880 --> 00:10:00.279 +0.1 second and look at how many users have + +00:10:00.280 --> 00:10:02.439 +it so we have 56% which is like + +00:10:02.440 --> 00:10:09.439 +44% users have less than 0.1 second gc duration + +00:10:09.440 --> 00:10:12.839 +and the rest 56% have more than 0.1 second. + +00:10:12.840 --> 00:10:16.279 +So you can see like more than half of users + +00:10:16.280 --> 00:10:20.559 +actually have noticeable gc delay + +00:10:20.560 --> 00:10:22.999 +so the Emacs freezes for some noticeable time + +00:10:23.000 --> 00:10:27.479 +and a quarter of users actually have very noticeable + +00:10:27.480 --> 00:10:31.799 +so like Emacs freezes such that you see an actual delay + +00:10:31.800 --> 00:10:36.879 +that Emacs actually has + +00:10:36.880 --> 00:10:44.079 +which is quite significant and important point. + +00:10:44.080 --> 00:10:47.719 +But apart from the duration of each individual gc + +00:10:47.720 --> 00:10:49.839 +it is important to see how frequent it is + +00:10:49.840 --> 00:10:52.879 +because even if you do notice a delay + +00:10:52.880 --> 00:10:54.959 +even a few seconds delay + +00:10:54.960 --> 00:10:56.999 +it doesn't matter if it happens once + +00:10:57.000 --> 00:10:59.199 +during the whole Emacs session. + +00:10:59.200 --> 00:11:05.039 +So if you look into frequency distribution again here + +00:11:05.040 --> 00:11:13.639 +I plot time between subsequent garbage collections + +00:11:13.640 --> 00:11:17.959 +versus how frequent it is and we have very clear trend + +00:11:17.960 --> 00:11:21.799 +that most of the garbage collections are quite frequent + +00:11:21.800 --> 00:11:25.159 +like we talk about every few seconds a few tens of seconds. + +00:11:25.160 --> 00:11:30.039 +There's a few outliers which are at very round numbers + +00:11:30.040 --> 00:11:35.839 +like 60 seconds, 120 seconds, 300 seconds. + +00:11:35.840 --> 00:11:37.879 +These are usually timers so like + +00:11:37.880 --> 00:11:40.319 +you have something running on timer + +00:11:40.320 --> 00:11:43.599 +and then it is complex command + +00:11:43.600 --> 00:11:45.079 +and it triggers garbage collection + +00:11:45.080 --> 00:11:48.079 +but it's not the majority. + +00:11:48.080 --> 00:11:51.279 +Again to run the numbers + +00:11:51.280 --> 00:11:53.679 +it's better to look into cumulative distribution + +00:11:53.680 --> 00:11:56.039 +and see that 50% of garbage collections + +00:11:56.040 --> 00:11:58.279 +are basically less than 10 seconds apart. + +00:11:58.280 --> 00:12:02.359 +And we can combine it with previous data + +00:12:02.360 --> 00:12:07.479 +and we look into whatever garbage collection + +00:12:07.480 --> 00:12:09.959 +takes less than 10 seconds from each other + +00:12:09.960 --> 00:12:13.119 +and also takes more than say 0.1 seconds. + +00:12:13.120 --> 00:12:15.319 +So and then we see that + +00:12:15.320 --> 00:12:17.639 +one quarter of all garbage collections + +00:12:17.640 --> 00:12:21.039 +are just noticeable and also frequent + +00:12:21.040 --> 00:12:23.679 +and 9% are not like + +00:12:23.680 --> 00:12:27.199 +more than 0.2% very noticeable and also frequent. + +00:12:27.200 --> 00:12:30.079 +So basically it constitutes Emacs freezing. + +00:12:30.080 --> 00:12:33.559 +So 9% of all the garbage collection Emacs freezing. + +00:12:33.560 --> 00:12:37.319 +Of course if you remember there is a bias + +00:12:37.320 --> 00:12:40.519 +but 9% is quite significant number. + +00:12:40.520 --> 00:12:44.319 +So garbage collection can really slow down things + +00:12:44.320 --> 00:12:48.239 +not for everyone but for significant fraction of users. + +00:12:48.240 --> 00:12:52.159 +Another thing I'd like to look into + +00:12:52.160 --> 00:12:55.399 +is what I call agglomerated GCs. + +00:12:55.400 --> 00:12:57.959 +What I mean by agglomerated is + +00:12:57.960 --> 00:13:00.359 +when you have one garbage collection + +00:13:00.360 --> 00:13:02.999 +and then another garbage immediately after it. + +00:13:03.000 --> 00:13:05.559 +So in terms of numbers I took + +00:13:05.560 --> 00:13:08.719 +every subsequent garbage collection + +00:13:08.720 --> 00:13:10.399 +which is either immediately after + +00:13:10.400 --> 00:13:13.039 +or no more than one second after each. + +00:13:13.040 --> 00:13:16.159 +So from point of view of users is like + +00:13:16.160 --> 00:13:19.999 +multiple garbage collection they add up together + +00:13:20.000 --> 00:13:22.999 +into one giant garbage collection. + +00:13:23.000 --> 00:13:25.839 +And if you look into numbers + +00:13:25.840 --> 00:13:29.559 +of how many agglomerated garbage collections there are + +00:13:29.560 --> 00:13:32.119 +you can see even numbers over 100. + +00:13:32.120 --> 00:13:35.479 +So 100 garbage collection going one after another. + +00:13:35.480 --> 00:13:39.159 +Even if you think about each garbage collection + +00:13:39.160 --> 00:13:42.719 +taking 0.1 second we look into 100 of them + +00:13:42.720 --> 00:13:44.639 +it's total 10 seconds. + +00:13:44.640 --> 00:13:46.839 +It's like Emacs hanging forever + +00:13:46.840 --> 00:13:53.519 +or like a significant number is also 10. + +00:13:53.520 --> 00:13:55.999 +So again this would be very annoying to meet such thing. + +00:13:56.000 --> 00:13:57.879 +How frequently does it happen? + +00:13:57.880 --> 00:14:00.279 +Again we can plot cumulative distribution + +00:14:00.280 --> 00:14:03.879 +and we see that 20 percent like 19 percent + +00:14:03.880 --> 00:14:07.199 +of all the garbage collection are at least two together + +00:14:07.200 --> 00:14:13.679 +and 8 percent like more than 10. So like you think about oh + +00:14:13.680 --> 00:14:15.639 +each garbage collection is not taking much time + +00:14:15.640 --> 00:14:24.479 +but when you have 10 of them yeah that becomes a problem. + +00:14:24.480 --> 00:14:29.919 +Another thing is to answer a question + +00:14:29.920 --> 00:14:32.959 +that some people complain about is that + +00:14:32.960 --> 00:14:35.799 +longer you use Emacs the slower Emacs become. + +00:14:35.800 --> 00:14:43.039 +Of course it may be caused by garbage collection + +00:14:43.040 --> 00:14:48.519 +and I wanted to look into how garbage collection time + +00:14:48.520 --> 00:14:49.679 +and other statistics, + +00:14:49.680 --> 00:14:53.199 +other parameters are evolving over time. + +00:14:53.200 --> 00:14:58.559 +And what I can see here is a cumulative distribution + +00:14:58.560 --> 00:15:03.719 +of GC duration for like first 10 minutes of Emacs uptime + +00:15:03.720 --> 00:15:06.479 +first 100 minutes first 1000 minutes. + +00:15:06.480 --> 00:15:10.199 +And if you look closer then you see + +00:15:10.200 --> 00:15:14.519 +that each individual garbage collection on average + +00:15:14.520 --> 00:15:18.959 +takes longer as you use Emacs longer. + +00:15:18.960 --> 00:15:24.039 +However this longer is not much it's like maybe 10 percent + +00:15:24.040 --> 00:15:29.479 +like basically garbage collection gets like + +00:15:29.480 --> 00:15:34.719 +slow Emacs down more as you use Emacs more but not much. + +00:15:34.720 --> 00:15:38.359 +So basically if you do you see Emacs + +00:15:38.360 --> 00:15:40.639 +being slower and slower over time + +00:15:40.640 --> 00:15:43.159 +it's probably not really garbage collection + +00:15:43.160 --> 00:15:45.839 +because it doesn't change too much. + +00:15:45.840 --> 00:15:48.119 +And if you look into time + +00:15:48.120 --> 00:15:50.839 +between individual garbage collections + +00:15:50.840 --> 00:15:53.719 +and you see that the time actually increases + +00:15:53.720 --> 00:15:56.719 +as you use Emacs longer which makes sense + +00:15:56.720 --> 00:15:58.839 +because initially like first few minutes + +00:15:58.840 --> 00:16:01.479 +you have all kind of packages loading + +00:16:01.480 --> 00:16:04.239 +like all the port loading and then later + +00:16:04.240 --> 00:16:07.239 +everything is loaded and things become more stable. + +00:16:07.240 --> 00:16:12.879 +So the conclusion on this part is that + +00:16:12.880 --> 00:16:16.399 +if Emacs becomes slower in a long session + +00:16:16.400 --> 00:16:18.479 +it's probably not caused by garbage collection. + +00:16:18.480 --> 00:16:23.679 +And one word of warning of course is that + +00:16:23.680 --> 00:16:27.919 +it's all nice and all when I present the statistics + +00:16:27.920 --> 00:16:29.279 +but it's only an average + +00:16:29.280 --> 00:16:34.079 +and if you are an actual user like here is one example + +00:16:34.080 --> 00:16:37.159 +which shows a total garbage collection time + +00:16:37.160 --> 00:16:40.119 +like accumulated together over Emacs uptime + +00:16:40.120 --> 00:16:43.199 +and you see different lines + +00:16:43.200 --> 00:16:45.559 +which correspond to different sessions of one user + +00:16:45.560 --> 00:16:48.679 +and you see they are wildly different + +00:16:48.680 --> 00:16:51.439 +like one time there is almost no garbage collection + +00:16:51.440 --> 00:16:54.679 +another time you see garbage collection + +00:16:54.680 --> 00:16:56.999 +because probably Emacs is used more early + +00:16:57.000 --> 00:16:59.599 +or like different pattern of usage + +00:16:59.600 --> 00:17:03.159 +and even during a single Emacs session + +00:17:03.160 --> 00:17:04.599 +you see a different slope + +00:17:04.600 --> 00:17:06.439 +of this curve which means that + +00:17:06.440 --> 00:17:09.279 +sometimes garbage collection is infrequent + +00:17:09.280 --> 00:17:11.479 +and sometimes it's much more frequent + +00:17:11.480 --> 00:17:14.479 +so it's probably much more noticeable one time + +00:17:14.480 --> 00:17:15.639 +and less noticeable other time. + +00:17:15.640 --> 00:17:19.719 +So if you think about these statistics of course + +00:17:19.720 --> 00:17:23.359 +they only represent an average usage + +00:17:23.360 --> 00:17:26.359 but sometimes it can get worse sometimes it can get better. -17:30.320 --> 17:35.600 -The last parameter I'd like to talk about is garbage collection during Emacs init. +00:17:26.360 --> 00:17:33.759 +The last parameter I'd like to talk about is -17:36.960 --> 17:42.320 -Basically if you think about what happens during Emacs init like when Emacs just starting up +00:17:33.760 --> 00:17:35.799 +garbage collection during Emacs init. -17:42.320 --> 17:46.720 -then whatever garbage collection there it's one or it's several times +00:17:35.800 --> 00:17:40.439 +Basically if you think about what happens during Emacs init -17:46.720 --> 17:50.640 +00:17:40.440 --> 00:17:41.919 +like when Emacs just starting up + +00:17:41.920 --> 00:17:44.479 +then whatever garbage collection + +00:17:44.480 --> 00:17:46.759 +there it's one or it's several times + +00:17:46.760 --> 00:17:51.239 it all contributes to Emacs taking longer to start. -17:53.200 --> 18:00.640 -And again we can look into the statistic and see what is the total GC duration after Emacs init +00:17:51.240 --> 00:17:56.559 +And again we can look into the statistic + +00:17:56.560 --> 00:18:01.159 +and see what is the total GC duration after Emacs init + +00:18:01.160 --> 00:18:06.159 +and we see that 50% of all the submissions + +00:18:06.160 --> 00:18:10.279 +garbage collection adds up more than one second + +00:18:10.280 --> 00:18:14.919 +to Emacs init time and for 20% of users + +00:18:14.920 --> 00:18:17.079 +it's extra three seconds Emacs start time + +00:18:17.080 --> 00:18:18.479 +which is very significant + +00:18:18.480 --> 00:18:21.479 +especially for people who are used to Vim + +00:18:21.480 --> 00:18:23.919 +which can start in like a fraction of a second + +00:18:23.920 --> 00:18:26.239 +and here it just does garbage collection + +00:18:26.240 --> 00:18:27.439 +because garbage collection is not + +00:18:27.440 --> 00:18:29.239 +everything Emacs does during startup + +00:18:29.240 --> 00:18:31.999 +adds up more to the load. + +00:18:32.000 --> 00:18:36.119 +Okay that's all nice and all + +00:18:36.120 --> 00:18:38.679 +but what can we do about these statistics + +00:18:38.680 --> 00:18:40.159 +can we draw any conclusions + +00:18:40.160 --> 00:18:43.239 +and the answer is of course + +00:18:43.240 --> 00:18:46.079 +like the most important conclusion here is that + +00:18:46.080 --> 00:18:49.439 +yes garbage collection can slow down Emacs + +00:18:49.440 --> 00:18:52.679 +at least for some people and what to do about it + +00:18:52.680 --> 00:18:55.319 +there are two variables which you can tweak + +00:18:55.320 --> 00:18:58.719 +it's because gcconce threshold gcconce percentage + +00:18:58.720 --> 00:19:03.159 +and having the statistics I can at least look a little bit + +00:19:03.160 --> 00:19:08.879 +into what is the effect of increasing these variables + +00:19:08.880 --> 00:19:12.439 +like most people just increase gcconce threshold + +00:19:12.440 --> 00:19:16.959 +and like all the submissions people did increase + +00:19:16.960 --> 00:19:19.919 +and doesn't make much sense to decrease it -18:01.840 --> 18:10.240 -and we see that 50% of all the submissions garbage collection adds up more than one second +00:19:19.920 --> 00:19:21.079 +like to make things worse -18:10.240 --> 18:17.760 -to Emacs init time and for 20% of users it's extra three seconds Emacs start time which is +00:19:21.080 --> 00:19:27.639 +of course for these statistics -18:17.760 --> 18:22.640 -very significant especially for people who are used to Vim which can start in like a fraction +00:19:27.640 --> 00:19:31.559 +the exact values of this increased thresholds -18:22.640 --> 18:27.200 -of a second and here it just does garbage collection because garbage collection is +00:19:31.560 --> 00:19:33.839 +are not always the same -18:27.200 --> 18:31.760 -not everything Emacs does during startup adds up more to the load. +00:19:33.840 --> 00:19:36.479 +but at least we can look into some trends -18:33.680 --> 18:39.280 -Okay that's all nice and all but what can we do about these statistics can we draw any +00:19:36.480 --> 00:19:44.759 +so first and obvious thing we can observe -18:39.280 --> 18:46.000 -conclusions and the answer is of course like the most important conclusion here is that +00:19:44.760 --> 00:19:46.759 +is when we compare -18:46.720 --> 18:52.320 -yes garbage collection can slow down Emacs at least for some people and what to do about it +00:19:46.760 --> 00:19:50.399 +the standard gc settings standard thresholds -18:53.360 --> 18:58.720 -there are two variables which you can tweak it's because gcconce threshold gcconce percentage +00:19:50.400 --> 00:19:53.999 +and increased thresholds for time between -18:58.720 --> 19:06.400 -and having the statistics I can at least look a little bit into what is the effect of +00:19:54.000 --> 00:19:57.479 +subsequent gcs and as one may expect -19:06.400 --> 19:12.400 -increasing these variables like most people just increase gcconce threshold +00:19:57.480 --> 00:19:59.559 +if you increase the threshold -19:13.760 --> 19:17.040 -and like all the submissions people did increase and +00:19:59.560 --> 00:20:02.679 +Emacs will do garbage collection less frequently -19:17.680 --> 19:20.880 -doesn't make much sense to decrease it like to make things worse +00:20:02.680 --> 00:20:05.279 +so the spacing between garbage collection increases -19:24.560 --> 19:31.280 -of course for these statistics the exact values of this increased thresholds +00:20:05.280 --> 00:20:07.599 +okay the only thing is that -19:31.680 --> 19:36.320 -are not always the same but at least we can look into some trends +00:20:07.600 --> 00:20:10.719 +if garbage collection is less frequent -19:38.640 --> 19:48.480 -so first and obvious thing we can observe is when we compare the standard gc settings +00:20:10.720 --> 00:20:14.079 +then each individual garbage collection becomes longer -19:49.120 --> 19:57.680 -standard thresholds and increased thresholds for time between subsequent gcs and as one may expect +00:20:14.080 --> 00:20:18.159 +so if you think about increasing -19:57.680 --> 20:03.440 -if you increase the threshold Emacs will do garbage collection less frequently so the spacing +00:20:18.160 --> 00:20:22.239 +garbage collection thresholds be prepared -20:03.440 --> 20:10.080 -between garbage collection increases okay the only thing is that if garbage collection is +00:20:22.240 --> 00:20:26.519 +that in each individual time Emacs freezes will take longer -20:10.080 --> 20:16.800 -less frequent then each individual garbage collection becomes longer so if you think about +00:20:26.520 --> 00:20:31.599 +this is one caveat when we talk about -20:16.800 --> 20:24.240 -increasing garbage collection thresholds be prepared that in each individual time Emacs +00:20:31.600 --> 00:20:34.079 +this agglomerated gcs which are one after other -20:24.240 --> 20:33.040 -freezes will take longer this is one caveat when we talk about this agglomerated gcs which +00:20:34.080 --> 00:20:36.759 +like if you increase the threshold sufficiently -20:33.040 --> 20:40.160 -are one after other like if you increase the threshold sufficiently then whatever happened +00:20:36.760 --> 00:20:42.319 +then whatever happened that garbage collections -20:40.160 --> 20:46.880 -that garbage collections were like done one after other we can now make it so that they are actually +00:20:42.320 --> 00:20:44.399 +were like done one after other -20:46.880 --> 20:53.840 -separated so like you don't see one giant freeze caused by like 10 gcs in a row instead you can +00:20:44.400 --> 00:20:47.599 +we can now make it so that they are actually separated -20:53.840 --> 21:00.880 -make it so that they are separated and in statistics it's very clear that the number of +00:20:47.600 --> 00:20:51.559 +so like you don't see one giant freeze caused by -21:00.880 --> 21:06.560 -agglomerated garbage collections decreases dramatically when you increase the thresholds +00:20:51.560 --> 00:20:52.919 +like 10 gcs in a row -21:07.920 --> 21:11.600 +00:20:52.920 --> 00:20:55.759 +instead you can make it so that they are separated + +00:20:55.760 --> 00:20:59.079 +and in statistics it's very clear + +00:20:59.080 --> 00:21:02.959 +that the number of agglomerated garbage collections + +00:21:02.960 --> 00:21:06.919 +decreases dramatically when you increase the thresholds + +00:21:06.920 --> 00:21:11.759 it's particularly evident when we look into startup time -21:13.520 --> 21:19.680 -if you look at gc duration during Emacs startup and if we look into what happens when you +00:21:11.760 --> 00:21:17.279 +if you look at gc duration during Emacs startup + +00:21:17.280 --> 00:21:19.159 +and if we look into what happens + +00:21:19.160 --> 00:21:20.879 +when you increase the thresholds + +00:21:20.880 --> 00:21:23.799 +it's very clear that Emacs startup become faster + +00:21:23.800 --> 00:21:26.279 +when you increase gc thresholds + +00:21:26.280 --> 00:21:33.359 +so that's all for actual user statistics + +00:21:33.360 --> 00:21:35.439 +and now let's try to run into + +00:21:35.440 --> 00:21:38.079 +some like actual recommendations + +00:21:38.080 --> 00:21:42.639 +on what numbers to set and before we start + +00:21:42.640 --> 00:21:44.399 +let me explain a little bit about + +00:21:44.400 --> 00:21:46.479 +the difference between these two variables + +00:21:46.480 --> 00:21:48.879 +which is gc constant threshold and gc constant percentage + +00:21:48.880 --> 00:21:52.359 +so if you think about Emacs memory + +00:21:52.360 --> 00:21:55.239 +like there's a certain memory allocated by Emacs + +00:21:55.240 --> 00:21:58.479 +and then as you run commands and turn using Emacs + +00:21:58.480 --> 00:22:00.079 +there is more memory allocated + +00:22:00.080 --> 00:22:04.639 +and Emacs decides when to do garbage collection + +00:22:04.640 --> 00:22:06.079 +according these two variables + +00:22:06.080 --> 00:22:08.759 +and actually what it does it chooses the larger one + +00:22:08.760 --> 00:22:12.119 +so say you have you are late in Emacs session + +00:22:12.120 --> 00:22:14.039 +you have a lot of Emacs memory allocated + +00:22:14.040 --> 00:22:17.119 +then you have gc constant percentage + +00:22:17.120 --> 00:22:19.919 +which is percent of the already allocated memory + +00:22:19.920 --> 00:22:25.119 +and that percent is probably going to be the largest + +00:22:25.120 --> 00:22:28.319 +because you have more memory + +00:22:28.320 --> 00:22:32.559 +and memory means that percent of it is larger + +00:22:32.560 --> 00:22:36.359 +so like you have a larger number cost + +00:22:36.360 --> 00:22:37.719 +by gc constant percentage + +00:22:37.720 --> 00:22:43.079 +so in this scenario when Emacs session is already running + +00:22:43.080 --> 00:22:45.319 +for a long time and there is a lot of memory allocated + +00:22:45.320 --> 00:22:50.119 +you have gc constant percentage + +00:22:50.120 --> 00:22:52.279 +controlling the garbage collection + +00:22:52.280 --> 00:22:54.999 +while early in Emacs there is not much memory placed + +00:22:55.000 --> 00:22:58.719 +Emacs just starting up then gc constant threshold + +00:22:58.720 --> 00:23:01.639 +is controlling how frequently garbage collection happens + +00:23:01.640 --> 00:23:04.799 +because smaller allocated memory -21:19.680 --> 21:25.680 -increase the thresholds it's very clear that Emacs startup become faster when you increase gc +00:23:04.800 --> 00:23:06.839 +means its percentage will be a small number -21:25.680 --> 21:37.120 -thresholds so that's all for actual user statistics and now let's try to run into some like actual +00:23:06.840 --> 00:23:12.319 +so in terms of default values at least -21:37.120 --> 21:44.480 -recommendations on what numbers to set and before we start let me explain a little bit about +00:23:12.320 --> 00:23:14.239 +gc constant threshold is 800 kilobytes -21:44.480 --> 21:48.720 -the difference between these two variables which is gc constant threshold and gc constant percentage +00:23:14.240 --> 00:23:18.799 +and gc constant percentage is 10 -21:49.440 --> 21:55.120 -so if you think about Emacs memory like there's a certain memory allocated by Emacs +00:23:18.800 --> 00:23:24.159 +so gc constant percentage becomes larger than that threshold -21:56.000 --> 22:00.000 -and then as you run commands and turn using Emacs there is more memory allocated +00:23:24.160 --> 00:23:28.919 +when you have more than eight megabytes of allocated memory -22:01.360 --> 22:07.120 -and Emacs decides when to do garbage collection according these two variables and actually what +00:23:28.920 --> 00:23:31.039 +by Emacs which is quite early -22:07.120 --> 22:12.880 -it does it chooses the larger one so say you have you are late in Emacs session you have a lot of +00:23:31.040 --> 00:23:34.279 +and it will probably hold just during the startup -22:12.880 --> 22:18.960 -Emacs memory allocated then you have gc constant percentage which is percent of the already +00:23:34.280 --> 00:23:36.799 +and once you start using your maximum -22:18.960 --> 22:27.360 -allocated memory and that percent is probably going to be the largest because you have more memory and +00:23:36.800 --> 00:23:38.919 +and once you load all the histories -22:28.800 --> 22:34.480 -memory means that percent of it is larger so like you have a larger number +00:23:38.920 --> 00:23:42.039 +all the kinds of buffers it's probably going to take -22:35.040 --> 22:41.680 -cost by gc constant percentage so in this scenario when Emacs session is +00:23:42.040 --> 00:23:43.959 +more than much more than eight megabytes -22:42.240 --> 22:46.880 -already running for a long time and there is a lot of memory allocated you have +00:23:43.960 --> 00:23:50.639 +so now we understand this -22:49.600 --> 22:54.240 -gc constant percentage controlling the garbage collection while early in Emacs there is not much +00:23:50.640 --> 00:23:53.279 +we can draw certain recommendations -22:54.240 --> 23:00.240 -memory placed Emacs just starting up then gc constant threshold is controlling how frequently +00:23:53.280 --> 00:23:57.279 +about tweaking the gc thresholds -23:00.240 --> 23:06.160 -garbage collection happens because smaller allocated memory means its percentage will be a +00:23:57.280 --> 00:24:01.159 +so first of all I need to emphasize -23:06.160 --> 23:14.080 -small number so in terms of default values at least gc constant threshold is 800 kilobytes +00:24:01.160 --> 00:24:03.639 +that any time you increase gc threshold -23:14.800 --> 23:24.080 -and gc constant percentage is 10 so gc constant percentage becomes larger than that threshold +00:24:03.640 --> 00:24:07.199 +an individual garbage collection time increases -23:24.080 --> 23:30.480 -when you have more than eight megabytes of allocated memory by Emacs which is quite early +00:24:07.200 --> 00:24:08.759 +so it's not free at all -23:30.480 --> 23:37.040 -and it will probably hold just during the startup and once you start using your maximum +00:24:08.760 --> 00:24:10.999 +if you don't have problems with garbage collection -23:37.040 --> 23:42.080 -and once you load all the histories all the kinds of buffers it's probably going to take +00:24:11.000 --> 00:24:13.519 +which is half of the users don't have much problem -23:42.080 --> 23:52.320 -more than much more than eight megabytes so now we understand this we can draw certain +00:24:13.520 --> 00:24:15.079 +you don't need to tweak anything -23:52.320 --> 24:00.960 -recommendations about tweaking the gc thresholds so first of all I need to emphasize that +00:24:15.080 --> 00:24:19.359 +only when gc is frequent and slow -24:01.760 --> 24:07.840 -any time you increase gc threshold an individual garbage collection time increases so it's not +00:24:19.360 --> 00:24:23.399 +when Emacs is really really present frequently -24:07.840 --> 24:12.320 -free at all if you don't have problems with garbage collection which is half of the users +00:24:23.400 --> 00:24:27.119 +you may consider increasing gc thresholds only -24:12.320 --> 24:19.360 -don't have much problem you don't need to tweak anything only when gc is frequent and slow +00:24:27.120 --> 00:24:31.479 +and in particular I recommend -24:19.360 --> 24:27.040 -when Emacs is really really present frequently you may consider increasing gc thresholds only +00:24:31.480 --> 00:24:33.279 +increasing gc constant percentage -24:28.240 --> 24:35.040 -and in particular I recommend increasing gc constant percentage because that's what mostly +00:24:33.280 --> 00:24:36.359 +because that's what mostly controls gc -24:35.040 --> 24:43.600 -controls gc when Emacs is running for long session and the numbers are probably like +00:24:36.360 --> 00:24:40.079 +when Emacs is running for long session -24:43.600 --> 24:48.640 -yeah we can estimate the effect of these numbers like for example if you have a default value of +00:24:40.080 --> 00:24:43.039 +and the numbers are probably like -24:48.640 --> 24:54.720 -0.1 percent for gc constant percentage 0.1 which is 10 percent and then increase it twice +00:24:43.040 --> 00:24:46.519 +yeah we can estimate the effect of these numbers -24:55.760 --> 25:02.880 -obviously you get twice less frequent gcs but it will come at the cost of extra 10 percent gc time +00:24:46.520 --> 00:24:49.679 +like for example if you have a default value of 0.1 percent -25:02.880 --> 25:09.840 -and if you increase 10 times you can think about 10 less 10 x less frequent gcs but almost twice +00:24:49.680 --> 00:24:52.759 +for gc constant percentage 0.1 which is 10 percent -25:09.840 --> 25:16.880 -longer individual garbage collection time so probably you want to set the number closer to 0.1 +00:24:52.760 --> 00:24:55.039 +and then increase it twice -25:19.520 --> 25:29.280 -another part of the users may actually try to optimize Emacs startup time which is quite frequent +00:24:55.040 --> 00:24:58.639 +obviously you get twice less frequent gcs -25:29.280 --> 25:37.200 -problem in this case it's probably better to increase gc constant but not too much so like +00:24:58.640 --> 00:25:02.559 +but it will come at the cost of extra 10 percent gc time -25:37.200 --> 25:42.640 -first of all it makes sense to check whether garbage collection is a problem at all during +00:25:02.560 --> 00:25:05.839 +and if you increase 10 times you can think about -25:43.520 --> 25:48.160 -startup and there are two variables which can show what is happening +00:25:05.840 --> 00:25:08.719 +10 less 10 x less frequent gcs -25:49.120 --> 25:54.800 -this garbage collection so gc done is a variable that shows how many garbage collection +00:25:08.720 --> 00:25:12.199 +but almost twice longer individual garbage collection time -25:57.520 --> 26:02.560 -like what is the number of garbage collections triggered like when you check the value or +00:25:12.200 --> 00:25:16.919 +so probably you want to set the number closer to 0.1 -26:02.560 --> 26:08.320 -right after you start Emacs you will see that number and gc elapsed variable +00:25:16.920 --> 00:25:23.399 +another part of the users may actually -26:09.280 --> 26:15.440 -which gives you a number of seconds which Emacs spent in doing garbage collection so this is +00:25:23.400 --> 00:25:28.359 +try to optimize Emacs startup time -26:15.440 --> 26:20.800 -probably the most important variable and if you see it's large then you may consider tweaking it +00:25:28.360 --> 00:25:30.759 +which is quite frequent problem -26:20.800 --> 26:30.000 -for the Emacs startup we can estimate some bounds because in the statistics I never saw anything +00:25:30.760 --> 00:25:34.919 +in this case it's probably better to increase gc constant -26:30.000 --> 26:35.600 -that is more than 10 seconds extra which even 10 seconds is probably like a really really hard +00:25:34.920 --> 00:25:38.199 +but not too much so like -26:35.600 --> 26:45.280 -upper bound so or say if you want to decrease the gc contribution like order of magnitude +00:25:38.200 --> 00:25:40.239 +first of all it makes sense to check -26:45.920 --> 26:52.080 -or like two orders of magnitudes let's say like as a really hard top estimate then it +00:25:40.240 --> 00:25:43.319 +whether garbage collection is a problem at all -26:52.080 --> 27:00.080 -corresponds to 80 megabytes gc constant and probably much less so like there's no point +00:25:43.320 --> 00:25:45.999 +during startup and there are two variables -27:00.080 --> 27:06.880 -setting it to a few hundred megabytes of course there's one caveat which is important to keep in +00:25:46.000 --> 00:25:50.199 +which can show what is happening this garbage collection -27:06.880 --> 27:16.800 -mind though that increasing the gc thresholds is not just increasing individual gc time +00:25:50.200 --> 00:25:53.719 +so gc done is a variable that shows -27:16.800 --> 27:23.600 -there's also an actual real impact on the RAM usage so like if you increase gc threshold +00:25:53.720 --> 00:25:55.039 +how many garbage collection -27:24.400 --> 27:29.600 -it increases the RAM usage of Emacs and you shouldn't think that like okay I increased +00:25:55.040 --> 00:26:00.159 +like what is the number of garbage collections triggered -27:30.480 --> 27:37.200 -the threshold by like 100 megabytes then 100 megabytes extra RAM usage doesn't matter +00:26:00.160 --> 00:26:02.599 +like when you check the value -27:37.200 --> 27:44.480 -it's not 100 megabytes because less frequent garbage collection means it will lead to +00:26:02.600 --> 00:26:04.039 +or right after you start Emacs -27:44.480 --> 27:51.680 -memory fragmentation so in practice if you increase the thresholds to tens or hundreds +00:26:04.040 --> 00:26:04.799 +you will see that -27:51.680 --> 27:58.240 -of megabytes we are talking about gigabytes extra RAM usage for me personally when I tried to +00:26:04.800 --> 00:26:08.519 +number and gc elapsed variable -27:58.240 --> 28:05.200 -play with gc thresholds I have seen Emacs taking two gigabytes like compared to several times less +00:26:08.520 --> 00:26:11.599 +which gives you a number of seconds -28:05.760 --> 28:12.240 -when with default settings so it's not free at all and only like either when you have a lot of +00:26:11.600 --> 00:26:14.959 +which Emacs spent in doing garbage collection -28:12.240 --> 28:19.440 -free RAM and you don't care or when your Emacs is really slow then you may need to consider this +00:26:14.960 --> 00:26:16.879 +so this is probably the most important variable -28:19.440 --> 28:24.160 -tweaking these defaults so again don't tweak defaults if you don't really have a problem +00:26:16.880 --> 00:26:20.719 +and if you see it's large then you may consider tweaking it -28:24.800 --> 28:31.360 -and of course this RAM problem is a big big deal for Emacs devs because from +00:26:20.720 --> 00:26:26.799 +for the Emacs startup we can estimate some bounds -28:32.960 --> 28:38.400 -from the point of single user you have like normal laptop most likely like normal PC with a lot of +00:26:26.800 --> 00:26:30.039 +because in the statistics I never saw anything -28:38.400 --> 28:45.760 -RAM you don't care about these things too much but Emacs in general can run on like +00:26:30.040 --> 00:26:32.439 +that is more than 10 seconds extra -28:46.320 --> 28:53.200 -all kinds of machines including low-end machines with very limited RAM and anytime Emacs developers +00:26:32.440 --> 00:26:34.439 +which even 10 seconds is probably like -28:53.280 --> 29:00.320 -consider increasing the defaults for garbage collection it's like they always have to consider +00:26:34.440 --> 00:26:39.119 +a really really hard upper bound so -29:00.320 --> 29:06.800 -if you increase them too much then Emacs may just stop running on certain platforms +00:26:39.120 --> 00:26:44.479 +or say if you want to decrease the gc contribution -29:09.840 --> 29:15.600 -so that's a very big consideration in terms of the global defaults for everyone +00:26:44.480 --> 00:26:47.479 +like order of magnitude or like two orders of magnitudes -29:16.320 --> 29:24.560 -although I have to I would say that it might be related to the safe to increase GCCons threshold +00:26:47.480 --> 00:26:50.879 +let's say like as a really hard top estimate -29:24.560 --> 29:29.600 -because it mostly affects startup and during startup it's probably not the peak usage of +00:26:50.880 --> 00:26:55.079 +then it corresponds to 80 megabytes gc constant -29:30.560 --> 29:38.160 -Emacs and like as Emacs runs for longer it's probably where most of RAM will be used later +00:26:55.080 --> 00:26:58.959 +and probably much less so like -29:38.720 --> 29:43.920 -on the other hand GCCons percentage is much more debating because it has pros and cons +00:26:58.960 --> 00:27:00.679 +there's no point setting it -29:43.920 --> 29:48.880 -it will increase the RAM usage it will increase the individual GC time so +00:27:00.680 --> 00:27:04.159 +to a few hundred megabytes of course -29:50.240 --> 29:56.560 -if we consider changing it it's much more tricky and we have discussing probably measure the impact +00:27:04.160 --> 00:27:08.439 +there's one caveat which is important to keep in -29:56.560 --> 30:06.080 -on users and a final note on or from the point of view of Emacs development is that +00:27:08.440 --> 00:27:14.039 +mind though that increasing the gc thresholds -30:06.480 --> 30:11.440 -this simple mark-and-sweep algorithm is like a very old and not the state-of-the-art algorithm +00:27:14.040 --> 00:27:16.399 +is not just increasing individual gc time -30:13.040 --> 30:16.960 -there are variants of garbage collection that are like totally non-blocking +00:27:16.400 --> 00:27:20.399 +there's also an actual real impact on the RAM usage -30:18.000 --> 30:22.720 -so Emacs just doesn't have to freeze during the garbage collection or there are variants +00:27:20.400 --> 00:27:23.839 +so like if you increase gc threshold -30:22.720 --> 30:27.440 -of garbage collection algorithm that do not scan all the memory just fraction of it +00:27:23.840 --> 00:27:26.879 +it increases the RAM usage of Emacs -30:28.640 --> 30:35.520 -and scan another fraction less frequently so there are actually ways just to +00:27:26.880 --> 00:27:29.639 +and you shouldn't think that like okay -30:36.480 --> 30:39.680 -change the garbage collection algorithm to make things much faster +00:27:29.640 --> 00:27:33.159 +I increased the threshold by like 100 megabytes -30:40.400 --> 30:47.280 -of course like just changing the numbers of variables like the numbers of variable values +00:27:33.160 --> 00:27:37.119 +then 100 megabytes extra RAM usage doesn't matter -30:47.280 --> 30:52.000 -is much more tricky and one has to implement it obviously it would be nice if someone implements +00:27:37.120 --> 00:27:38.679 +it's not 100 megabytes -30:52.000 --> 30:58.720 -it but so far it's not happening so yeah it would be nice but maybe not not so quickly +00:27:38.680 --> 00:27:42.319 +because less frequent garbage collection means -30:59.600 --> 31:02.080 +00:27:42.320 --> 00:27:45.639 +it will lead to memory fragmentation + +00:27:45.640 --> 00:27:50.439 +so in practice if you increase the thresholds + +00:27:50.440 --> 00:27:52.799 +to tens or hundreds of megabytes + +00:27:52.800 --> 00:27:55.919 +we are talking about gigabytes extra RAM usage + +00:27:55.920 --> 00:27:59.719 +for me personally when I tried to play with gc thresholds + +00:27:59.720 --> 00:28:02.879 +I have seen Emacs taking two gigabytes like + +00:28:02.880 --> 00:28:05.519 +compared to several times less + +00:28:05.520 --> 00:28:09.039 +when with default settings so it's not free at all + +00:28:09.040 --> 00:28:13.639 +and only like either when you have a lot of free RAM + +00:28:13.640 --> 00:28:16.839 +and you don't care or when your Emacs is really slow + +00:28:16.840 --> 00:28:19.559 +then you may need to consider this + +00:28:19.560 --> 00:28:23.239 +tweaking these defaults so again don't tweak defaults + +00:28:23.240 --> 00:28:24.239 +if you don't really have a problem + +00:28:24.240 --> 00:28:29.839 +and of course this RAM problem is a big big deal + +00:28:29.840 --> 00:28:35.679 +for Emacs devs because from from the point of single user + +00:28:35.680 --> 00:28:38.839 +you have like normal laptop most likely like normal PC + +00:28:38.840 --> 00:28:42.079 +with a lot of RAM you don't care about these things too much + +00:28:42.080 --> 00:28:48.999 +but Emacs in general can run on like all kinds of machines + +00:28:49.000 --> 00:28:51.679 +including low-end machines with very limited RAM + +00:28:51.680 --> 00:28:55.359 +and anytime Emacs developers consider increasing + +00:28:55.360 --> 00:28:57.959 +the defaults for garbage collection + +00:28:57.960 --> 00:29:01.479 +it's like they always have to consider + +00:29:01.480 --> 00:29:02.959 +if you increase them too much + +00:29:02.960 --> 00:29:07.919 +then Emacs may just stop running on certain platforms + +00:29:07.920 --> 00:29:14.439 +so that's a very big consideration in terms + +00:29:14.440 --> 00:29:16.639 +of the global defaults for everyone + +00:29:16.640 --> 00:29:22.199 +although I have to I would say that it might be related + +00:29:22.200 --> 00:29:24.479 +to the safe to increase GCCons threshold + +00:29:24.480 --> 00:29:27.919 +because it mostly affects startup and during startup + +00:29:27.920 --> 00:29:31.279 +it's probably not the peak usage of Emacs + +00:29:31.280 --> 00:29:35.599 +and like as Emacs runs for longer + +00:29:35.600 --> 00:29:38.199 +it's probably where most of RAM will be used later + +00:29:38.200 --> 00:29:44.399 +on the other hand GCCons percentage is much more debating + +00:29:44.400 --> 00:29:46.159 +because it has pros and cons + +00:29:46.160 --> 00:29:47.719 +it will increase the RAM usage + +00:29:47.720 --> 00:29:50.999 +it will increase the individual GC time so + +00:29:51.000 --> 00:29:56.119 +if we consider changing it it's much more tricky + +00:29:56.120 --> 00:29:59.479 +and we have discussing probably measure the impact on users + +00:29:59.480 --> 00:30:05.799 +and a final note on or from the point of view + +00:30:05.800 --> 00:30:07.319 +of Emacs development is + +00:30:07.320 --> 00:30:11.039 +that this simple mark-and-sweep algorithm + +00:30:11.040 --> 00:30:14.119 +is like a very old and not the state-of-the-art algorithm + +00:30:14.120 --> 00:30:17.799 +there are variants of garbage collection + +00:30:17.800 --> 00:30:19.479 +that are like totally non-blocking + +00:30:19.480 --> 00:30:22.479 +so Emacs just doesn't have to freeze + +00:30:22.480 --> 00:30:24.279 +during the garbage collection + +00:30:24.280 --> 00:30:26.839 +or there are variants of garbage collection algorithm + +00:30:26.840 --> 00:30:30.079 +that do not scan all the memory just fraction of it + +00:30:30.080 --> 00:30:33.439 +and scan another fraction less frequently + +00:30:33.440 --> 00:30:36.999 +so there are actually ways just to change + +00:30:37.000 --> 00:30:39.799 +the garbage collection algorithm to make things much faster + +00:30:39.800 --> 00:30:44.199 +of course like just changing the numbers of variables + +00:30:44.200 --> 00:30:47.079 +like the numbers of variable values + +00:30:47.080 --> 00:30:50.079 +is much more tricky and one has to implement it + +00:30:50.080 --> 00:30:52.239 +obviously it would be nice if someone implements it + +00:30:52.240 --> 00:30:55.639 +but so far it's not happening so yeah it would be nice + +00:30:55.640 --> 00:30:59.359 +but maybe not not so quickly + +00:30:59.360 --> 00:31:02.159 there is more chance to change the defaults here -31:02.240 --> 31:05.680 +00:31:02.160 --> 00:31:07.479 to conclude let me reiterate the most important points -31:06.640 --> 31:12.400 -so from point of view of users you need to understand that yes garbage collection may be +00:31:07.480 --> 00:31:11.919 +so from point of view of users you need to understand that + +00:31:11.920 --> 00:31:14.479 +yes garbage collection may be a problem + +00:31:14.480 --> 00:31:16.679 +but not for everyone so like + +00:31:16.680 --> 00:31:21.079 +you should only think about changing the variables + +00:31:21.080 --> 00:31:23.559 +when you really know that garbage collection + +00:31:23.560 --> 00:31:27.479 +is the problem for you so if you have slow Emacs startup + +00:31:27.480 --> 00:31:30.919 +slow Emacs startup and you know that it's caused by + +00:31:30.920 --> 00:31:32.479 +garbage collection like by + +00:31:32.480 --> 00:31:35.999 +you can check the GC elapsed variable + +00:31:36.000 --> 00:31:39.679 +then you may increase GC count threshold + +00:31:39.680 --> 00:31:42.119 +like to few tens of megabytes not more + +00:31:42.120 --> 00:31:44.479 +it doesn't make sense to increase it much more + +00:31:44.480 --> 00:31:48.239 +and if you really have major problems + +00:31:48.240 --> 00:31:49.759 +with Emacs being slaggy + +00:31:49.760 --> 00:31:52.519 +then you can increase GC count percentage + +00:31:52.520 --> 00:31:55.999 +to like 0.2 0.3 maybe + +00:31:56.000 --> 00:31:57.679 +one is probably overkill + +00:31:57.680 --> 00:32:02.759 +but do watch your Emacs ROM usage it may be really impacted + +00:32:02.760 --> 00:32:09.719 +for Emacs developers I'd like to emphasize + +00:32:09.720 --> 00:32:12.439 +that there is a real problem with garbage collection + +00:32:12.440 --> 00:32:17.959 +and nine percent of all the garbage collection -31:12.400 --> 31:20.480 -a problem but not for everyone so like you should only think about changing the variables when you +00:32:17.960 --> 00:32:22.079 +data points we have correspond -31:20.480 --> 31:28.240 -really know that garbage collection is the problem for you so if you have slow Emacs startup +00:32:22.080 --> 00:32:24.959 +to really slow noticeable Emacs precision -31:28.400 --> 31:34.000 -slow Emacs startup and you know that it's caused by garbage collection like by you can check the +00:32:24.960 --> 00:32:28.039 +and really frequent less than 10 seconds -31:34.000 --> 31:41.520 -GC elapsed variable then you may increase GC count threshold like to few tens of megabytes +00:32:28.040 --> 00:32:32.319 +I'd say that it's really worth -31:41.520 --> 31:48.160 -not more it doesn't make sense to increase it much more and if you really have major problems +00:32:32.320 --> 00:32:35.279 +increasing GC count threshold at least during startup -31:48.160 --> 31:56.080 -with Emacs being slaggy then you can increase GC count percentage to like 0.2 0.3 maybe +00:32:35.280 --> 00:32:40.159 +because it really impacts the Emacs startup time -31:56.080 --> 32:02.640 -one is probably overkill but do watch your Emacs ROM usage it may be really impacted +00:32:40.160 --> 00:32:41.519 +making Emacs startup much faster -32:04.160 --> 32:12.400 -for Emacs developers I'd like to emphasize that there is a real problem with garbage collection +00:32:41.520 --> 00:32:44.799 +ideally we need to reimplement -32:12.400 --> 32:22.720 -and nine percent of all the garbage collection data points we have correspond to really slow +00:32:44.800 --> 00:32:48.599 +the garbage collection algorithm of course it's not easy -32:22.720 --> 32:27.920 -noticeable Emacs precision and really frequent less than 10 seconds +00:32:48.600 --> 00:32:50.159 +but it would be really nice -32:30.000 --> 32:35.120 -I'd say that it's really worth increasing GC count threshold at least during startup +00:32:50.160 --> 00:32:56.399 +and for GC count percentage defaults it's hard to say -32:36.400 --> 32:41.440 -because it really impacts the Emacs startup time making Emacs startup much faster +00:32:56.400 --> 00:33:00.759 +we may consider changing it but it's up to discussion -32:42.400 --> 32:48.560 -ideally we need to reimplement the garbage collection algorithm of course it's not easy +00:33:00.760 --> 00:33:03.119 +and we probably need to be conservative here -32:48.560 --> 32:56.880 -but it would be really nice and for GC count percentage defaults it's hard to say we may +00:33:03.120 --> 00:33:06.039 +so we came to the end of my talk -32:56.880 --> 33:03.040 -consider changing it but it's up to discussion and we probably need to be conservative here +00:33:06.040 --> 00:33:09.319 +and this presentation -33:04.320 --> 33:11.280 -so we came to the end of my talk and this presentation all the data will be available +00:33:09.320 --> 00:33:11.839 +all the data will be available publicly -33:11.280 --> 33:21.760 -publicly and you can reproduce all the statistic graphs if you wish and thank you for attention +00:33:11.840 --> 00:33:17.079 +and you can reproduce all the statistic graphs if you wish +00:33:17.080 --> 00:33:21.920 +and thank you for attention |