blob: c1bea8de622cf7eaf608363861800d84e3a3f045 (
plain) (
tree)
|
|
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
|
