Hello everyone, my name is Igor Achinko and you may know me from Org Mailing List.
However, today I'm not going to talk about Org Mode. Today I'm going to talk about
Emacs performance and how it's affected by its memory management code.
First, I will introduce the basic concepts of Emacs memory management and what garbage
collection is. Then I will show you user statistics collected from volunteer users
over the last half year and I will end with some guidelines on how to tweak Emacs garbage
collection customizations to optimize Emacs performance and when it's necessary or not
to do. Let's begin. What is garbage collection? To understand what is garbage collection we need
to realize that anything you do in Emacs is some kind of command and any command is most likely
running some Elisp code and every time you run Elisp code you most likely need to locate certain
memory in RAM and some of this memory is retained for a long time and some of this memory is
transient. Of course, Emacs has to clear this transient memory from time to time to not occupy
all the possible RAM in the computer. In this small example we have one global variable
that is assigned a value but when assigning the value we first allocate a temporary variable
and then a temporary list and only retain some part of this list in this global variable.
In terms of memory graph we can represent this as two variable slots, one transient, one permanent
and then a list of three concerns and part of which is retained as a global variable but part
of it which is a temporary variable symbol and the first term of the list is not used and it
might be cleared at some point. So that's what Emacs does. Every now and then Emacs goes through
all the memory and identify which part of the memory are not used and then clear them so that
it can free up the RAM. This process is called garbage collection and Emacs uses a very simple
and old algorithm which is called mark and sweep. So during this mark and sweep process
is basically two stages. First Emacs scans all the memory that is allocated and then identify
which memory is still in use which is linked to some variables for example and which memory is
not used anymore even though it was allocated in the past and the second stage is clear that
whatever a memory is not that is not allocated. During the process
Emacs cannot do anything now. So basically every time Emacs scans the memory it freezes up and
doesn't respond to anything and if it takes too much time so that users can notice it then of
course Emacs is not responsive at all and if this garbage collection is triggered too frequently
then it's not just not responsive every now and then it's also not responsive all the time almost
all the time so it cannot even normally type or stuff or do some normal commands.
This mark and sweep algorithm is taking longer the more memory Emacs uses. So basically
the more buffers you open, the more packages you load, the more complex commands you run,
the more memory is used and basically the longer Emacs takes to perform a single garbage collection.
Of course Emacs being Emacs and this garbage collection can be tweaked. In particular
users can tweak how frequently Emacs does garbage collection using two basic variables
GCConsThreshold and GCConsPercentage. GCConsThreshold is the raw number of kilobytes
Emacs needs to allocate before triggering another garbage collection and the GCConsPercentage
is similar but it's defined in terms of fraction of already allocated memory.
If you follow various Emacs forums you may be familiar with people complaining about
garbage collection and there are many many suggestions about what to do with it.
Most frequently you see GCConsThreshold
recommended to be increased and a number of pre-packaged Emacs distributions like
DoMeEmacs do increase it or like I have seen suggestions which are actually horrible to
disable garbage collection temporarily or for a long time.
Which is nice you can see it quite frequently which indicates there might be some problem.
However every time like one user poses about this problem it's just one data point and it doesn't
mean that everyone actually suffers from it. It doesn't mean that everyone should do it.
So in order to understand if this garbage collection is really a problem which is a
common problem we do need some kind of statistics and only using the actual statistics we can
understand if it should be recommended for everyone to tweak the defaults or like whether
it should be recommended for certain users or maybe it should be asked Emacs devs to do
something about the defaults. And what I did some time ago is exactly this. I tried to collect the
user statistics. So I wrote a small package on Elp and some users installed this package and
then reported back these statistics of the garbage collection for their particular use.
By now we have obtained 129 user submissions with over 1 million GC records in there.
So like some of these submissions used default GC settings without any customizations.
Some used increased GC cost threshold and GC cost percentage.
So using this data we can try to draw some reliable conclusions on what should be done
and whether should anything be done about garbage collection on Emacs dev level or at least on user
level. Of course we need to keep in mind that there's some kind of bias because it's more
likely that users already have problems with GC or they think they have problems with GC will report
and submit the data. But anyway having s statistics is much more useful than just
having anecdotal evidences from one or other reddit posts. And just one thing I will do
during the rest of my presentation is that for all the statistics I will normalize
user data so that every user contributes equally. For example if one user submits like 100 hours
Emacs uptime statistics and other users submit one hour Emacs uptime then I will
anyway make it so that they contribute equally.
Let's start from one of the most obvious things we can look into is which is the time it takes
for garbage collection to single garbage collection process. Here you see
frequency distribution of GC duration for all the 129 users we got and
you can see that most of the garbage collections are done quite quickly in less than 0.1 second
and less than 0.1 second is usually just not noticeable. So even though there is garbage
collection it will not interrupt the work in Emacs. However there is a fraction of users who
experience garbage collection it takes like 0.2, 0.3 or even half a second which will be quite
noticeable. For the purposes of this study I will consider that anything that is less than 0.1
second which is insignificant so like you will not notice it and it's like obviously all the Emacs
usage will be just normal. But if it's more than 0.1 or 0.2 seconds then it will be very noticeable
and you will see that Emacs hang for a little while or not so little while. In terms of numbers
it's better to plot the statistics not as a distribution but as a cumulative distribution.
So like at every point of this graph you'll see like for example here 0.4 seconds
you have this percent of like almost 90% of users have no more than 0.4 gc duration. So like
we can look here if we take one gc critical gc duration which is 0.1 second
0.1 second and look at how many users have it so we have 56% which is like
44% users have less than 0.1 second gc duration and the rest 56% have more than 0.1 second.
So you can see like more than half of users actually have noticeable gc delay so the
Emacs freezes for some noticeable time and a quarter of users actually have very noticeable
so like Emacs freezes such that you see an actual delay that Emacs actually has
which is quite significant and important point. But apart from the duration of each individual gc
it is important to see how frequent it is because even if you do notice a delay
even a few seconds delay it doesn't matter if it happens once during the whole Emacs session.
So if you look into frequency distribution again here I plot time between
subsequent garbage collections versus how frequent it is and we have very clear trend that
most of the garbage collections are quite frequent like we talk about every few seconds a few tens
of seconds. There's a few outliers which are at very round numbers like 60 seconds, 120 seconds,
300 seconds. These are usually timers so like you have something running on timer and then it
is complex command and it triggers garbage collection but it's not the majority.
Again to run the numbers it's better to look into cumulative distribution and see that
50% of garbage collections are basically less than 10 seconds apart.
And we can combine it with previous data and we look into whatever garbage collection takes
less than 10 seconds from each other and also takes more than say 0.1 seconds.
So and then we see that one quarter of all garbage collections are just noticeable and also frequent
and 9% are not like more than 0.2% very noticeable and also frequent. So basically
it constitutes Emacs freezing. So 9% of all the garbage collection Emacs freezing. Of course
if you remember there is a bias but 9% is quite significant number. So garbage collection can
really slow down things not for everyone but for significant fraction of users.
Another thing I'd like to look into is what I call agglomerated GCs. What I mean by agglomerated
is when you have one garbage collection and then another garbage immediately after it. So
in terms of numbers I took every subsequent garbage collection which is either immediately
after or no more than one second after each. So from point of view of users is like
multiple garbage collection they add up together into one giant garbage collection.
And if you look into numbers of how many agglomerated garbage collections there are
you can see even numbers over 100. So 100 garbage collection going one after another.
Even if you think about each garbage collection taking 0.1 second we look into 100 of them
it's total 10 seconds. It's like Emacs hanging forever or like a significant number is also 10.
So again this would be very annoying to meet such thing. How frequently does it happen? Again we
can plot cumulative distribution and we see that 20 percent like 19 percent of all the garbage
collection are at least two together and 8 percent like more than 10. So like you think about oh
each garbage collection is not taking much time but when you have 10 of them yeah that becomes a
problem. Another thing is to answer a question that some people complain about is that
longer you use Emacs the slower Emacs become. Of course it may be caused by garbage collection and
I wanted to look into how garbage collection time and other statistics, other parameters
are evolving over time. And what I can see here is a cumulative distribution of GC duration
for like first 10 minutes of Emacs uptime first 100 minutes first 1000 minutes.
And if you look closer then you see that each individual garbage collection on average
takes longer as you use Emacs longer. However this longer is not much it's like maybe 10 percent
like basically garbage collection gets like slow Emacs down more as you use Emacs more
but not much. So basically if you do you see Emacs being slower and slower over time
it's probably not really garbage collection because it doesn't change too much. And if you
look into time between individual garbage collections and you see that the time actually
increases as you use Emacs longer which makes sense because initially like first few minutes
you have all kind of packages loading like all the port loading and then later everything is
loaded and things become more stable. So the conclusion on this part is that
if Emacs becomes slower in a long session it's probably not caused by garbage collection.
And one word of warning of course is that it's all nice and all when I present the statistics
but it's only an average and if you are an actual user like here is one example
which shows a total garbage collection time like accumulated together over Emacs uptime
and you see different lines which correspond to different sessions of one user
and you see they are wildly different like one time there is almost no garbage collection
another time you see garbage collection because probably Emacs is used more early or like
different pattern of usage and even during a single Emacs session you see a different slope
of this curve which means that sometimes garbage collection is infrequent and sometimes it's much
more frequent so it's probably much more noticeable one time and less noticeable other time.
So if you think about these statistics of course they only represent an average usage
but sometimes it can get worse sometimes it can get better.
The last parameter I'd like to talk about is garbage collection during Emacs init.
Basically if you think about what happens during Emacs init like when Emacs just starting up
then whatever garbage collection there it's one or it's several times
it all contributes to Emacs taking longer to start.
And again we can look into the statistic and see what is the total GC duration after Emacs init
and we see that 50% of all the submissions garbage collection adds up more than one second
to Emacs init time and for 20% of users it's extra three seconds Emacs start time which is
very significant especially for people who are used to Vim which can start in like a fraction
of a second and here it just does garbage collection because garbage collection is
not everything Emacs does during startup adds up more to the load.
Okay that's all nice and all but what can we do about these statistics can we draw any
conclusions and the answer is of course like the most important conclusion here is that
yes garbage collection can slow down Emacs at least for some people and what to do about it
there are two variables which you can tweak it's because gcconce threshold gcconce percentage
and having the statistics I can at least look a little bit into what is the effect of
increasing these variables like most people just increase gcconce threshold
and like all the submissions people did increase and
doesn't make much sense to decrease it like to make things worse
of course for these statistics the exact values of this increased thresholds
are not always the same but at least we can look into some trends
so first and obvious thing we can observe is when we compare the standard gc settings
standard thresholds and increased thresholds for time between subsequent gcs and as one may expect
if you increase the threshold Emacs will do garbage collection less frequently so the spacing
between garbage collection increases okay the only thing is that if garbage collection is
less frequent then each individual garbage collection becomes longer so if you think about
increasing garbage collection thresholds be prepared that in each individual time Emacs
freezes will take longer this is one caveat when we talk about this agglomerated gcs which
are one after other like if you increase the threshold sufficiently then whatever happened
that garbage collections were like done one after other we can now make it so that they are actually
separated so like you don't see one giant freeze caused by like 10 gcs in a row instead you can
make it so that they are separated and in statistics it's very clear that the number of
agglomerated garbage collections decreases dramatically when you increase the thresholds
it's particularly evident when we look into startup time
if you look at gc duration during Emacs startup and if we look into what happens when you
increase the thresholds it's very clear that Emacs startup become faster when you increase gc
thresholds so that's all for actual user statistics and now let's try to run into some like actual
recommendations on what numbers to set and before we start let me explain a little bit about
the difference between these two variables which is gc constant threshold and gc constant percentage
so if you think about Emacs memory like there's a certain memory allocated by Emacs
and then as you run commands and turn using Emacs there is more memory allocated
and Emacs decides when to do garbage collection according these two variables and actually what
it does it chooses the larger one so say you have you are late in Emacs session you have a lot of
Emacs memory allocated then you have gc constant percentage which is percent of the already
allocated memory and that percent is probably going to be the largest because you have more memory and
memory means that percent of it is larger so like you have a larger number
cost by gc constant percentage so in this scenario when Emacs session is
already running for a long time and there is a lot of memory allocated you have
gc constant percentage controlling the garbage collection while early in Emacs there is not much
memory placed Emacs just starting up then gc constant threshold is controlling how frequently
garbage collection happens because smaller allocated memory means its percentage will be a
small number so in terms of default values at least gc constant threshold is 800 kilobytes
and gc constant percentage is 10 so gc constant percentage becomes larger than that threshold
when you have more than eight megabytes of allocated memory by Emacs which is quite early
and it will probably hold just during the startup and once you start using your maximum
and once you load all the histories all the kinds of buffers it's probably going to take
more than much more than eight megabytes so now we understand this we can draw certain
recommendations about tweaking the gc thresholds so first of all I need to emphasize that
any time you increase gc threshold an individual garbage collection time increases so it's not
free at all if you don't have problems with garbage collection which is half of the users
don't have much problem you don't need to tweak anything only when gc is frequent and slow
when Emacs is really really present frequently you may consider increasing gc thresholds only
and in particular I recommend increasing gc constant percentage because that's what mostly
controls gc when Emacs is running for long session and the numbers are probably like
yeah we can estimate the effect of these numbers like for example if you have a default value of
0.1 percent for gc constant percentage 0.1 which is 10 percent and then increase it twice
obviously you get twice less frequent gcs but it will come at the cost of extra 10 percent gc time
and if you increase 10 times you can think about 10 less 10 x less frequent gcs but almost twice
longer individual garbage collection time so probably you want to set the number closer to 0.1
another part of the users may actually try to optimize Emacs startup time which is quite frequent
problem in this case it's probably better to increase gc constant but not too much so like
first of all it makes sense to check whether garbage collection is a problem at all during
startup and there are two variables which can show what is happening
this garbage collection so gc done is a variable that shows how many garbage collection
like what is the number of garbage collections triggered like when you check the value or
right after you start Emacs you will see that number and gc elapsed variable
which gives you a number of seconds which Emacs spent in doing garbage collection so this is
probably the most important variable and if you see it's large then you may consider tweaking it
for the Emacs startup we can estimate some bounds because in the statistics I never saw anything
that is more than 10 seconds extra which even 10 seconds is probably like a really really hard
upper bound so or say if you want to decrease the gc contribution like order of magnitude
or like two orders of magnitudes let's say like as a really hard top estimate then it
corresponds to 80 megabytes gc constant and probably much less so like there's no point
setting it to a few hundred megabytes of course there's one caveat which is important to keep in
mind though that increasing the gc thresholds is not just increasing individual gc time
there's also an actual real impact on the RAM usage so like if you increase gc threshold
it increases the RAM usage of Emacs and you shouldn't think that like okay I increased
the threshold by like 100 megabytes then 100 megabytes extra RAM usage doesn't matter
it's not 100 megabytes because less frequent garbage collection means it will lead to
memory fragmentation so in practice if you increase the thresholds to tens or hundreds
of megabytes we are talking about gigabytes extra RAM usage for me personally when I tried to
play with gc thresholds I have seen Emacs taking two gigabytes like compared to several times less
when with default settings so it's not free at all and only like either when you have a lot of
free RAM and you don't care or when your Emacs is really slow then you may need to consider this
tweaking these defaults so again don't tweak defaults if you don't really have a problem
and of course this RAM problem is a big big deal for Emacs devs because from
from the point of single user you have like normal laptop most likely like normal PC with a lot of
RAM you don't care about these things too much but Emacs in general can run on like
all kinds of machines including low-end machines with very limited RAM and anytime Emacs developers
consider increasing the defaults for garbage collection it's like they always have to consider
if you increase them too much then Emacs may just stop running on certain platforms
so that's a very big consideration in terms of the global defaults for everyone
although I have to I would say that it might be related to the safe to increase GCCons threshold
because it mostly affects startup and during startup it's probably not the peak usage of
Emacs and like as Emacs runs for longer it's probably where most of RAM will be used later
on the other hand GCCons percentage is much more debating because it has pros and cons
it will increase the RAM usage it will increase the individual GC time so
if we consider changing it it's much more tricky and we have discussing probably measure the impact
on users and a final note on or from the point of view of Emacs development is that
this simple mark-and-sweep algorithm is like a very old and not the state-of-the-art algorithm
there are variants of garbage collection that are like totally non-blocking
so Emacs just doesn't have to freeze during the garbage collection or there are variants
of garbage collection algorithm that do not scan all the memory just fraction of it
and scan another fraction less frequently so there are actually ways just to
change the garbage collection algorithm to make things much faster
of course like just changing the numbers of variables like the numbers of variable values
is much more tricky and one has to implement it obviously it would be nice if someone implements
it but so far it's not happening so yeah it would be nice but maybe not not so quickly
there is more chance to change the defaults here
to conclude let me reiterate the most important points
so from point of view of users you need to understand that yes garbage collection may be
a problem but not for everyone so like you should only think about changing the variables when you
really know that garbage collection is the problem for you so if you have slow Emacs startup
slow Emacs startup and you know that it's caused by garbage collection like by you can check the
GC elapsed variable then you may increase GC count threshold like to few tens of megabytes
not more it doesn't make sense to increase it much more and if you really have major problems
with Emacs being slaggy then you can increase GC count percentage to like 0.2 0.3 maybe
one is probably overkill but do watch your Emacs ROM usage it may be really impacted
for Emacs developers I'd like to emphasize that there is a real problem with garbage collection
and nine percent of all the garbage collection data points we have correspond to really slow
noticeable Emacs precision and really frequent less than 10 seconds
I'd say that it's really worth increasing GC count threshold at least during startup
because it really impacts the Emacs startup time making Emacs startup much faster
ideally we need to reimplement the garbage collection algorithm of course it's not easy
but it would be really nice and for GC count percentage defaults it's hard to say we may
consider changing it but it's up to discussion and we probably need to be conservative here
so we came to the end of my talk and this presentation all the data will be available
publicly and you can reproduce all the statistic graphs if you wish and thank you for attention