diff options
Diffstat (limited to '')
| -rw-r--r-- | 2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt | 848 | ||||
| -rw-r--r-- | 2023/info/gc-before.md | 4 |
2 files changed, 850 insertions, 2 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 new file mode 100644 index 00000000..c1bea8de --- /dev/null +++ b/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt @@ -0,0 +1,848 @@ +WEBVTT + +00:00.000 --> 00:06.480 +Hello everyone, my name is Igor Achinko and you may know me from Org Mailing List. + +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:11.760 --> 00:16.800 +Emacs performance and how it's affected by its memory management code. + +00:18.880 --> 00:24.720 +First, I will introduce the basic concepts of Emacs memory management and what garbage + +00:24.720 --> 00:32.320 +collection is. Then I will show you user statistics collected from volunteer users + +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:42.080 --> 00:48.640 +collection customizations to optimize Emacs performance and when it's necessary or not + +00:49.120 --> 00:56.560 +to do. Let's begin. What is garbage collection? To understand what is garbage collection we need + +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 + +01:01.920 --> 01:07.280 +running some Elisp code and every time you run Elisp code you most likely need to locate certain + +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 + +01:14.160 --> 01:20.320 +transient. Of course, Emacs has to clear this transient memory from time to time to not occupy + +01:20.320 --> 01:27.200 +all the possible RAM in the computer. In this small example we have one global variable + +01:28.480 --> 01:35.600 +that is assigned a value but when assigning the value we first allocate a temporary variable + +01:35.600 --> 01:41.360 +and then a temporary list and only retain some part of this list in this global variable. + +01:42.240 --> 01:51.920 +In terms of memory graph we can represent this as two variable slots, one transient, one permanent + +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 + +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 + +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 + +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 + +02:20.320 --> 02:27.760 +it can free up the RAM. This process is called garbage collection and Emacs uses a very simple + +02:27.760 --> 02:33.440 +and old algorithm which is called mark and sweep. So during this mark and sweep process + +02:33.440 --> 02:40.880 +is basically two stages. First Emacs scans all the memory that is allocated and then identify + +02:40.880 --> 02:46.320 +which memory is still in use which is linked to some variables for example and which memory is + +02:46.320 --> 02:51.600 +not used anymore even though it was allocated in the past and the second stage is clear that + +02:51.600 --> 02:56.240 +whatever a memory is not that is not allocated. During the process + +02:56.880 --> 03:03.920 +Emacs cannot do anything now. So basically every time Emacs scans the memory it freezes up and + +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 + +03:09.840 --> 03:18.160 +course Emacs is not responsive at all and if this garbage collection is triggered too frequently + +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 + +03:24.000 --> 03:29.840 +all the time so it cannot even normally type or stuff or do some normal commands. + +03:32.320 --> 03:40.080 +This mark and sweep algorithm is taking longer the more memory Emacs uses. So basically + +03:40.080 --> 03:46.480 +the more buffers you open, the more packages you load, the more complex commands you run, + +03:46.480 --> 03:55.840 +the more memory is used and basically the longer Emacs takes to perform a single garbage collection. + +04:00.560 --> 04:07.280 +Of course Emacs being Emacs and this garbage collection can be tweaked. In particular + +04:07.280 --> 04:12.960 +users can tweak how frequently Emacs does garbage collection using two basic variables + +04:12.960 --> 04:19.840 +GCConsThreshold and GCConsPercentage. GCConsThreshold is the raw number of kilobytes + +04:21.440 --> 04:27.200 +Emacs needs to allocate before triggering another garbage collection and the GCConsPercentage + +04:27.200 --> 04:31.680 +is similar but it's defined in terms of fraction of already allocated memory. + +04:33.840 --> 04:41.840 +If you follow various Emacs forums you may be familiar with people complaining about + +04:41.840 --> 04:47.760 +garbage collection and there are many many suggestions about what to do with it. + +04:50.320 --> 04:52.640 +Most frequently you see GCConsThreshold + +04:54.640 --> 05:01.280 +recommended to be increased and a number of pre-packaged Emacs distributions like + +05:01.280 --> 05:07.280 +DoMeEmacs do increase it or like I have seen suggestions which are actually horrible to + +05:07.280 --> 05:11.120 +disable garbage collection temporarily or for a long time. + +05:14.240 --> 05:19.600 +Which is nice you can see it quite frequently which indicates there might be some problem. + +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 + +05:26.320 --> 05:30.000 +mean that everyone actually suffers from it. It doesn't mean that everyone should do it. + +05:30.720 --> 05:37.680 +So in order to understand if this garbage collection is really a problem which is a + +05:37.680 --> 05:48.000 +common problem we do need some kind of statistics and only using the actual statistics we can + +05:48.000 --> 05:54.880 +understand if it should be recommended for everyone to tweak the defaults or like whether + +05:54.880 --> 06:00.000 +it should be recommended for certain users or maybe it should be asked Emacs devs to do + +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 + +06:08.800 --> 06:18.000 +user statistics. So I wrote a small package on Elp and some users installed this package and + +06:18.000 --> 06:24.080 +then reported back these statistics of the garbage collection for their particular use. + +06:25.360 --> 06:33.840 +By now we have obtained 129 user submissions with over 1 million GC records in there. + +06:35.760 --> 06:42.320 +So like some of these submissions used default GC settings without any customizations. + +06:42.320 --> 06:47.040 +Some used increased GC cost threshold and GC cost percentage. + +06:48.880 --> 06:56.640 +So using this data we can try to draw some reliable conclusions on what should be done + +06:56.640 --> 07:02.480 +and whether should anything be done about garbage collection on Emacs dev level or at least on user + +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 + +07:08.240 --> 07:13.680 +likely that users already have problems with GC or they think they have problems with GC will report + +07:14.480 --> 07:20.240 +and submit the data. But anyway having s statistics is much more useful than just + +07:20.240 --> 07:28.240 +having anecdotal evidences from one or other reddit posts. And just one thing I will do + +07:28.880 --> 07:33.280 +during the rest of my presentation is that for all the statistics I will normalize + +07:33.520 --> 07:41.440 +user data so that every user contributes equally. For example if one user submits like 100 hours + +07:41.440 --> 07:46.640 +Emacs uptime statistics and other users submit one hour Emacs uptime then I will + +07:47.200 --> 07:49.520 +anyway make it so that they contribute equally. + +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 + +07:59.360 --> 08:05.520 +for garbage collection to single garbage collection process. Here you see + +08:08.240 --> 08:16.240 +frequency distribution of GC duration for all the 129 users we got and + +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 + +08:27.440 --> 08:33.680 +and less than 0.1 second is usually just not noticeable. So even though there is garbage + +08:33.680 --> 08:43.200 +collection it will not interrupt the work in Emacs. However there is a fraction of users who + +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 + +08:49.680 --> 08:58.800 +noticeable. For the purposes of this study I will consider that anything that is less than 0.1 + +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 + +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 + +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 + +09:21.360 --> 09:28.000 +it's better to plot the statistics not as a distribution but as a cumulative distribution. + +09:29.040 --> 09:34.080 +So like at every point of this graph you'll see like for example here 0.4 seconds + +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 + +09:49.040 --> 09:55.760 +we can look here if we take one gc critical gc duration which is 0.1 second + +09:55.840 --> 10:02.400 +0.1 second and look at how many users have it so we have 56% which is like + +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. + +10:13.600 --> 10:20.720 +So you can see like more than half of users actually have noticeable gc delay so the + +10:20.720 --> 10:27.040 +Emacs freezes for some noticeable time and a quarter of users actually have very noticeable + +10:27.040 --> 10:36.640 +so like Emacs freezes such that you see an actual delay that Emacs actually has + +10:37.760 --> 10:47.600 +which is quite significant and important point. But apart from the duration of each individual gc + +10:47.600 --> 10:52.640 +it is important to see how frequent it is because even if you do notice a delay + +10:53.440 --> 10:59.120 +even a few seconds delay it doesn't matter if it happens once during the whole Emacs session. + +11:01.360 --> 11:10.720 +So if you look into frequency distribution again here I plot time between + +11:11.680 --> 11:17.760 +subsequent garbage collections versus how frequent it is and we have very clear trend that + +11:18.560 --> 11:24.560 +most of the garbage collections are quite frequent like we talk about every few seconds a few tens + +11:24.560 --> 11:32.560 +of seconds. There's a few outliers which are at very round numbers like 60 seconds, 120 seconds, + +11:32.560 --> 11:40.640 +300 seconds. These are usually timers so like you have something running on timer and then it + +11:41.440 --> 11:48.000 +is complex command and it triggers garbage collection but it's not the majority. + +11:49.280 --> 11:54.000 +Again to run the numbers it's better to look into cumulative distribution and see that + +11:54.000 --> 11:58.160 +50% of garbage collections are basically less than 10 seconds apart. + +12:00.000 --> 12:07.920 +And we can combine it with previous data and we look into whatever garbage collection takes + +12:07.920 --> 12:12.960 +less than 10 seconds from each other and also takes more than say 0.1 seconds. + +12:13.680 --> 12:20.800 +So and then we see that one quarter of all garbage collections are just noticeable and also frequent + +12:21.760 --> 12:27.840 +and 9% are not like more than 0.2% very noticeable and also frequent. So basically + +12:27.840 --> 12:34.480 +it constitutes Emacs freezing. So 9% of all the garbage collection Emacs freezing. Of course + +12:35.360 --> 12:42.960 +if you remember there is a bias but 9% is quite significant number. So garbage collection can + +12:42.960 --> 12:47.280 +really slow down things not for everyone but for significant fraction of users. + +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 + +12:57.440 --> 13:02.720 +is when you have one garbage collection and then another garbage immediately after it. So + +13:03.680 --> 13:09.840 +in terms of numbers I took every subsequent garbage collection which is either immediately + +13:09.840 --> 13:16.000 +after or no more than one second after each. So from point of view of users is like + +13:16.960 --> 13:22.880 +multiple garbage collection they add up together into one giant garbage collection. + +13:23.440 --> 13:29.440 +And if you look into numbers of how many agglomerated garbage collections there are + +13:29.440 --> 13:35.360 +you can see even numbers over 100. So 100 garbage collection going one after another. + +13:36.720 --> 13:42.560 +Even if you think about each garbage collection taking 0.1 second we look into 100 of them + +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. + +13:50.480 --> 13:58.160 +So again this would be very annoying to meet such thing. How frequently does it happen? Again we + +13:58.160 --> 14:04.400 +can plot cumulative distribution and we see that 20 percent like 19 percent of all the garbage + +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 + +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 + +14:17.840 --> 14:32.560 +problem. Another thing is to answer a question that some people complain about is that + +14:33.680 --> 14:42.320 +longer you use Emacs the slower Emacs become. Of course it may be caused by garbage collection and + +14:42.720 --> 14:50.000 +I wanted to look into how garbage collection time and other statistics, other parameters + +14:50.880 --> 14:58.880 +are evolving over time. And what I can see here is a cumulative distribution of GC duration + +14:59.680 --> 15:04.720 +for like first 10 minutes of Emacs uptime first 100 minutes first 1000 minutes. + +15:05.520 --> 15:13.840 +And if you look closer then you see that each individual garbage collection on average + +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 + +15:24.000 --> 15:33.040 +like basically garbage collection gets like slow Emacs down more as you use Emacs more + +15:33.680 --> 15:40.320 +but not much. So basically if you do you see Emacs being slower and slower over time + +15:40.960 --> 15:46.960 +it's probably not really garbage collection because it doesn't change too much. And if you + +15:46.960 --> 15:52.720 +look into time between individual garbage collections and you see that the time actually + +15:52.720 --> 15:58.880 +increases as you use Emacs longer which makes sense because initially like first few minutes + +15:58.880 --> 16:04.720 +you have all kind of packages loading like all the port loading and then later everything is + +16:04.720 --> 16:12.560 +loaded and things become more stable. So the conclusion on this part is that + +16:13.520 --> 16:18.480 +if Emacs becomes slower in a long session it's probably not caused by garbage collection. + +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 + +16:27.760 --> 16:32.800 +but it's only an average and if you are an actual user like here is one example + +16:34.080 --> 16:39.920 +which shows a total garbage collection time like accumulated together over Emacs uptime + +16:40.880 --> 16:45.360 +and you see different lines which correspond to different sessions of one user + +16:46.800 --> 16:51.360 +and you see they are wildly different like one time there is almost no garbage collection + +16:52.240 --> 16:57.840 +another time you see garbage collection because probably Emacs is used more early or like + +16:57.840 --> 17:04.560 +different pattern of usage and even during a single Emacs session you see a different slope + +17:04.560 --> 17:10.560 +of this curve which means that sometimes garbage collection is infrequent and sometimes it's much + +17:10.560 --> 17:16.000 +more frequent so it's probably much more noticeable one time and less noticeable other time. + +17:16.000 --> 17:23.360 +So if you think about these statistics of course they only represent an average usage + +17:23.360 --> 17:26.240 +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. + +17:36.960 --> 17:42.320 +Basically if you think about what happens during Emacs init like when Emacs just starting up + +17:42.320 --> 17:46.720 +then whatever garbage collection there it's one or it's several times + +17:46.720 --> 17:50.640 +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 + +18:01.840 --> 18:10.240 +and we see that 50% of all the submissions garbage collection adds up more than one second + +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 + +18:17.760 --> 18:22.640 +very significant especially for people who are used to Vim which can start in like a fraction + +18:22.640 --> 18:27.200 +of a second and here it just does garbage collection because garbage collection is + +18:27.200 --> 18:31.760 +not everything Emacs does during startup adds up more to the load. + +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 + +18:39.280 --> 18:46.000 +conclusions and the answer is of course like the most important conclusion here is that + +18:46.720 --> 18:52.320 +yes garbage collection can slow down Emacs at least for some people and what to do about it + +18:53.360 --> 18:58.720 +there are two variables which you can tweak it's because gcconce threshold gcconce percentage + +18:58.720 --> 19:06.400 +and having the statistics I can at least look a little bit into what is the effect of + +19:06.400 --> 19:12.400 +increasing these variables like most people just increase gcconce threshold + +19:13.760 --> 19:17.040 +and like all the submissions people did increase and + +19:17.680 --> 19:20.880 +doesn't make much sense to decrease it like to make things worse + +19:24.560 --> 19:31.280 +of course for these statistics the exact values of this increased thresholds + +19:31.680 --> 19:36.320 +are not always the same but at least we can look into some trends + +19:38.640 --> 19:48.480 +so first and obvious thing we can observe is when we compare the standard gc settings + +19:49.120 --> 19:57.680 +standard thresholds and increased thresholds for time between subsequent gcs and as one may expect + +19:57.680 --> 20:03.440 +if you increase the threshold Emacs will do garbage collection less frequently so the spacing + +20:03.440 --> 20:10.080 +between garbage collection increases okay the only thing is that if garbage collection is + +20:10.080 --> 20:16.800 +less frequent then each individual garbage collection becomes longer so if you think about + +20:16.800 --> 20:24.240 +increasing garbage collection thresholds be prepared that in each individual time Emacs + +20:24.240 --> 20:33.040 +freezes will take longer this is one caveat when we talk about this agglomerated gcs which + +20:33.040 --> 20:40.160 +are one after other like if you increase the threshold sufficiently then whatever happened + +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 + +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 + +20:53.840 --> 21:00.880 +make it so that they are separated and in statistics it's very clear that the number of + +21:00.880 --> 21:06.560 +agglomerated garbage collections decreases dramatically when you increase the thresholds + +21:07.920 --> 21:11.600 +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 + +21:19.680 --> 21:25.680 +increase the thresholds it's very clear that Emacs startup become faster when you increase gc + +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 + +21:37.120 --> 21:44.480 +recommendations on what numbers to set and before we start let me explain a little bit about + +21:44.480 --> 21:48.720 +the difference between these two variables which is gc constant threshold and gc constant percentage + +21:49.440 --> 21:55.120 +so if you think about Emacs memory like there's a certain memory allocated by Emacs + +21:56.000 --> 22:00.000 +and then as you run commands and turn using Emacs there is more memory allocated + +22:01.360 --> 22:07.120 +and Emacs decides when to do garbage collection according these two variables and actually what + +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 + +22:12.880 --> 22:18.960 +Emacs memory allocated then you have gc constant percentage which is percent of the already + +22:18.960 --> 22:27.360 +allocated memory and that percent is probably going to be the largest because you have more memory and + +22:28.800 --> 22:34.480 +memory means that percent of it is larger so like you have a larger number + +22:35.040 --> 22:41.680 +cost by gc constant percentage so in this scenario when Emacs session is + +22:42.240 --> 22:46.880 +already running for a long time and there is a lot of memory allocated you have + +22:49.600 --> 22:54.240 +gc constant percentage controlling the garbage collection while early in Emacs there is not much + +22:54.240 --> 23:00.240 +memory placed Emacs just starting up then gc constant threshold is controlling how frequently + +23:00.240 --> 23:06.160 +garbage collection happens because smaller allocated memory means its percentage will be a + +23:06.160 --> 23:14.080 +small number so in terms of default values at least gc constant threshold is 800 kilobytes + +23:14.800 --> 23:24.080 +and gc constant percentage is 10 so gc constant percentage becomes larger than that threshold + +23:24.080 --> 23:30.480 +when you have more than eight megabytes of allocated memory by Emacs which is quite early + +23:30.480 --> 23:37.040 +and it will probably hold just during the startup and once you start using your maximum + +23:37.040 --> 23:42.080 +and once you load all the histories all the kinds of buffers it's probably going to take + +23:42.080 --> 23:52.320 +more than much more than eight megabytes so now we understand this we can draw certain + +23:52.320 --> 24:00.960 +recommendations about tweaking the gc thresholds so first of all I need to emphasize that + +24:01.760 --> 24:07.840 +any time you increase gc threshold an individual garbage collection time increases so it's not + +24:07.840 --> 24:12.320 +free at all if you don't have problems with garbage collection which is half of the users + +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 + +24:19.360 --> 24:27.040 +when Emacs is really really present frequently you may consider increasing gc thresholds only + +24:28.240 --> 24:35.040 +and in particular I recommend increasing gc constant percentage because that's what mostly + +24:35.040 --> 24:43.600 +controls gc when Emacs is running for long session and the numbers are probably like + +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 + +24:48.640 --> 24:54.720 +0.1 percent for gc constant percentage 0.1 which is 10 percent and then increase it twice + +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 + +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 + +25:09.840 --> 25:16.880 +longer individual garbage collection time so probably you want to set the number closer to 0.1 + +25:19.520 --> 25:29.280 +another part of the users may actually try to optimize Emacs startup time which is quite frequent + +25:29.280 --> 25:37.200 +problem in this case it's probably better to increase gc constant but not too much so like + +25:37.200 --> 25:42.640 +first of all it makes sense to check whether garbage collection is a problem at all during + +25:43.520 --> 25:48.160 +startup and there are two variables which can show what is happening + +25:49.120 --> 25:54.800 +this garbage collection so gc done is a variable that shows how many garbage collection + +25:57.520 --> 26:02.560 +like what is the number of garbage collections triggered like when you check the value or + +26:02.560 --> 26:08.320 +right after you start Emacs you will see that number and gc elapsed variable + +26:09.280 --> 26:15.440 +which gives you a number of seconds which Emacs spent in doing garbage collection so this is + +26:15.440 --> 26:20.800 +probably the most important variable and if you see it's large then you may consider tweaking it + +26:20.800 --> 26:30.000 +for the Emacs startup we can estimate some bounds because in the statistics I never saw anything + +26:30.000 --> 26:35.600 +that is more than 10 seconds extra which even 10 seconds is probably like a really really hard + +26:35.600 --> 26:45.280 +upper bound so or say if you want to decrease the gc contribution like order of magnitude + +26:45.920 --> 26:52.080 +or like two orders of magnitudes let's say like as a really hard top estimate then it + +26:52.080 --> 27:00.080 +corresponds to 80 megabytes gc constant and probably much less so like there's no point + +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 + +27:06.880 --> 27:16.800 +mind though that increasing the gc thresholds is not just increasing individual gc time + +27:16.800 --> 27:23.600 +there's also an actual real impact on the RAM usage so like if you increase gc threshold + +27:24.400 --> 27:29.600 +it increases the RAM usage of Emacs and you shouldn't think that like okay I increased + +27:30.480 --> 27:37.200 +the threshold by like 100 megabytes then 100 megabytes extra RAM usage doesn't matter + +27:37.200 --> 27:44.480 +it's not 100 megabytes because less frequent garbage collection means it will lead to + +27:44.480 --> 27:51.680 +memory fragmentation so in practice if you increase the thresholds to tens or hundreds + +27:51.680 --> 27:58.240 +of megabytes we are talking about gigabytes extra RAM usage for me personally when I tried to + +27:58.240 --> 28:05.200 +play with gc thresholds I have seen Emacs taking two gigabytes like compared to several times less + +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 + +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 + +28:19.440 --> 28:24.160 +tweaking these defaults so again don't tweak defaults if you don't really have a problem + +28:24.800 --> 28:31.360 +and of course this RAM problem is a big big deal for Emacs devs because from + +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 + +28:38.400 --> 28:45.760 +RAM you don't care about these things too much but Emacs in general can run on like + +28:46.320 --> 28:53.200 +all kinds of machines including low-end machines with very limited RAM and anytime Emacs developers + +28:53.280 --> 29:00.320 +consider increasing the defaults for garbage collection it's like they always have to consider + +29:00.320 --> 29:06.800 +if you increase them too much then Emacs may just stop running on certain platforms + +29:09.840 --> 29:15.600 +so that's a very big consideration in terms of the global defaults for everyone + +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 + +29:24.560 --> 29:29.600 +because it mostly affects startup and during startup it's probably not the peak usage of + +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 + +29:38.720 --> 29:43.920 +on the other hand GCCons percentage is much more debating because it has pros and cons + +29:43.920 --> 29:48.880 +it will increase the RAM usage it will increase the individual GC time so + +29:50.240 --> 29:56.560 +if we consider changing it it's much more tricky and we have discussing probably measure the impact + +29:56.560 --> 30:06.080 +on users and a final note on or from the point of view of Emacs development is that + +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 + +30:13.040 --> 30:16.960 +there are variants of garbage collection that are like totally non-blocking + +30:18.000 --> 30:22.720 +so Emacs just doesn't have to freeze during the garbage collection or there are variants + +30:22.720 --> 30:27.440 +of garbage collection algorithm that do not scan all the memory just fraction of it + +30:28.640 --> 30:35.520 +and scan another fraction less frequently so there are actually ways just to + +30:36.480 --> 30:39.680 +change the garbage collection algorithm to make things much faster + +30:40.400 --> 30:47.280 +of course like just changing the numbers of variables like the numbers of variable values + +30:47.280 --> 30:52.000 +is much more tricky and one has to implement it obviously it would be nice if someone implements + +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 + +30:59.600 --> 31:02.080 +there is more chance to change the defaults here + +31:02.240 --> 31:05.680 +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 + +31:12.400 --> 31:20.480 +a problem but not for everyone so like you should only think about changing the variables when you + +31:20.480 --> 31:28.240 +really know that garbage collection is the problem for you so if you have slow Emacs startup + +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 + +31:34.000 --> 31:41.520 +GC elapsed variable then you may increase GC count threshold like to few tens of megabytes + +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 + +31:48.160 --> 31:56.080 +with Emacs being slaggy then you can increase GC count percentage to like 0.2 0.3 maybe + +31:56.080 --> 32:02.640 +one is probably overkill but do watch your Emacs ROM usage it may be really impacted + +32:04.160 --> 32:12.400 +for Emacs developers I'd like to emphasize that there is a real problem with garbage collection + +32:12.400 --> 32:22.720 +and nine percent of all the garbage collection data points we have correspond to really slow + +32:22.720 --> 32:27.920 +noticeable Emacs precision and really frequent less than 10 seconds + +32:30.000 --> 32:35.120 +I'd say that it's really worth increasing GC count threshold at least during startup + +32:36.400 --> 32:41.440 +because it really impacts the Emacs startup time making Emacs startup much faster + +32:42.400 --> 32:48.560 +ideally we need to reimplement the garbage collection algorithm of course it's not easy + +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 + +32:56.880 --> 33:03.040 +consider changing it but it's up to discussion and we probably need to be conservative here + +33:04.320 --> 33:11.280 +so we came to the end of my talk and this presentation all the data will be available + +33:11.280 --> 33:21.760 +publicly and you can reproduce all the statistic graphs if you wish and thank you for attention + diff --git a/2023/info/gc-before.md b/2023/info/gc-before.md index 6d53c92a..9513319f 100644 --- a/2023/info/gc-before.md +++ b/2023/info/gc-before.md @@ -8,12 +8,12 @@ The following image shows where the talk is in the schedule for Sun 2023-12-03. Format: 34-min talk; Q&A: BigBlueButton conference room <https://media.emacsconf.org/2023/current/bbb-gc.html> Etherpad: <https://pad.emacsconf.org/2023-gc> Discuss on IRC: [#emacsconf-dev](https://chat.emacsconf.org/?join=emacsconf,emacsconf-dev) -Status: Processing uploaded video +Status: Q&A open for participation <div>Times in different timezones:</div><div class="times" start="2023-12-03T18:00:00Z" end="2023-12-03T18:35:00Z"><div class="conf-time">Sunday, Dec 3 2023, ~1:00 PM - 1:35 PM EST (US/Eastern)</div><div class="others"><div>which is the same as:</div>Sunday, Dec 3 2023, ~12:00 PM - 12:35 PM CST (US/Central)<br />Sunday, Dec 3 2023, ~11:00 AM - 11:35 AM MST (US/Mountain)<br />Sunday, Dec 3 2023, ~10:00 AM - 10:35 AM PST (US/Pacific)<br />Sunday, Dec 3 2023, ~6:00 PM - 6:35 PM UTC <br />Sunday, Dec 3 2023, ~7:00 PM - 7:35 PM CET (Europe/Paris)<br />Sunday, Dec 3 2023, ~8:00 PM - 8:35 PM EET (Europe/Athens)<br />Sunday, Dec 3 2023, ~11:30 PM - 12:05 AM IST (Asia/Kolkata)<br />Monday, Dec 4 2023, ~2:00 AM - 2:35 AM +08 (Asia/Singapore)<br />Monday, Dec 4 2023, ~3:00 AM - 3:35 AM JST (Asia/Tokyo)</div></div><div><strong><a href="/2023/watch/dev/">Find out how to watch and participate</a></strong></div> - +<div class="vid"><video controls preload="none" id="gc-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.webm" />${captions}<p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 33:22 minutes<div class="files resources"><ul><li><a href="https://pad.emacsconf.org/2023-gc">Open Etherpad</a></li><li><a href="https://media.emacsconf.org/2023/current/bbb-gc.html">Open public Q&A</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.opus">Download --main.opus (22MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.txt">Download --main.txt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.webm">Download --main.webm (80MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--normalized.opus">Download --normalized.opus (30MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--original.mkv">Download --original.mkv (637MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--reencoded.webm">Download --reencoded.webm (72MB)</a></li></ul></div></div> # Description <!-- End of emacsconf-publish-before-page -->
\ No newline at end of file |