[Speaker 0]: And then, hi everyone.
Thank you for your nice talk,
I can say it's the Emacs GC.
We have some questions on the pad and maybe
before I would like to ask you something to
the last 1 you have said,
concerning changing the GC strategy,
that it's unlikely that it will be happening
in the next time. Yeah.
Is there any discussion going on or why does
the case it's not changing the strategy?
[Speaker 1]: It's mostly because it's difficult.
I think, yesterday you heard from,
1 of the dev talks that like there was 1
small, short comment that,
oh yeah, it would be nice to change this
algorithm but it's hard.
[Speaker 0]: So I
[Speaker 1]: mean it's hard not because the algorithm is
that hard but because it's a very low level
code and it must be like very carefully
weighted. So that can be,
it needs to be made sure that the carousel
will work. It's all bugs.
If you have bugs and you can see that,
so it's nothing to work anymore.
[Speaker 0]: So We have a lot of RAM usage.
Yeah. Maybe sometime.
[Speaker 1]: There was like years ago,
there was a branch on generational DC,
if I remember correctly,
but they didn't go anywhere,
unfortunately.
[Speaker 0]: That's a pity. But let's come to the
questions on the pad. So the first 1 is,
are the GC duration statistics correlated
with users? I mean, does the same user
experience GC of various durations?
Or Do some users experience GC of a greater
0.26 exclusively, while others never
experience them? So is it correlated to user
behavior? I guess you said it in your talk.
[Speaker 1]: Well, If you talk formally,
then almost every user has like 1 or 2
occasions when GC takes more than 0.2
seconds, but it's like,
maybe something else is using CPU and that's
why, but in practice, there are users who
don't have problem. Half of them that that's
who that's what I looked from statistics.
And dry users who have like really big
problems, like 1 second GC time.
[Speaker 0]: This is dependent on you make some comments
on us in the talk, but could you like extract
on if it's a package, that's a problem or we
as a user behavior are there.
[Speaker 1]: Usually it's something that is,
okay. I'm sharing my screen now,
[Speaker 0]: It's coming on, give it like 2 to 3 seconds.
[Speaker 1]: right? Yeah. So I can just click through
different user statistics.
So like you can see this duration for each
individual user basically.
So you can see like here for example it's
like averages around 0.25
seconds which is noticeable and here is like
0.1 like someone is all over the place,
probably some. Then like,
what else can we see here?
Yeah, some users like have sub 0.1,
no problem at all. And I have seen some that
really, really bad. I mean,
[Speaker 0]: if it's noticeable, it's all bad.
[Speaker 1]: So yeah. For example, here it's like 0.8
seconds, 0.5 seconds. I don't know how that
guy uses ZMax. Yeah. you can see it varies.
[Speaker 0]: So It varies quite a lot.
[Speaker 1]: What it depends on, like,
usually the number of packages,
like all kinds of timers going on under the
hood. I think I tried to list...
I'll go through this. I briefly outlined some
important parts. Here,
when you have something like an org agenda,
it will most likely trigger a lot of GCs.
When you have a lot of timers,
when you have something calculated on
modline, it will be frequently triggered.
[Speaker 0]: Well,
[Speaker 1]: yeah. When you have so many packages and
these packages are using a lot of memory.
Like I remember I was surprised by this,
package, home org that was,
caching all the results.
And for large org files,
it was like several hundred megabytes of
data. Well, it just becomes slower.
Yeah.
[Speaker 0]: Yeah. Maybe, maybe a short side note.
Someone asks, what software you're using for
flipping through the PNGs.
Maybe you could shortly throws it in.
[Speaker 1]: What do you mean? Here,
[Speaker 0]: I guess it was just simply,
[Speaker 1]: this, It's it's far. Yeah.
So
[Speaker 0]: yeah. So, question 1 and 2 answered.
To 1 statement you have made,
there was a question concerning the timings.
So you said, okay, everything above 0.1
second is fine. Maybe There's a short story
of someone who asked a question.
[Speaker 1]: I see the question is about scrolling,
[Speaker 0]: Yeah, exactly.
[Speaker 1]: right? Again, there's not much you can do in
terms of trying to adjust the GC time.
I mean, if you make GCs less frequent,
you increase the individual GC time.
If you make them more frequent,
you decrease the individual GC time,
but then they are more frequent.
So what is the point? I think the way to go
here is you can rise to see the short for the
duration of scrolling,
like just for a comment.
I think it's a recommendation from Emacs
devs. So like You do something along the
lines.
Yeah, I'm surely doing something on my screen
and I forgot that I'm not sharing anything.
[Speaker 0]: Exactly.
[Speaker 1]: Simply something like this.
So, basically, if you have some command that
is very important that it should run very
quickly. You temporary increase that
threshold, you run that comment,
then that's all. That's probably the best.
So basically, the best you can do is to delay
it after the command.
[Speaker 0]: So afterwards, it takes a lot of time to do
its stuff. OK. The third 1 has been already
answered, but I just want to get your
information from it. Opinions on the GCMH
mode.
[Speaker 1]: Okay. Yeah, I see that problem,
but that's more like a technical problem.
But there's another problem there.
Yeah, I prepared a small snippet here.
So if you look at the GCMH mode,
it has this concept of low threshold and high
threshold and most of the time it's running
high threshold and then when Emacs is idle,
it falls back to lower threshold and then it
does the GC while Emacs is not used.
That's a good idea, of course.
That's the core idea of GCMH mode.
Unfortunately, the most annoying GC is when
you're actively using max.
And then you have this huge value of GC
counter show and look at the doc stream.
This would be sector value that makes GC
unlikely but does not cost OSP Asian.
So yeah, no wonder like if you don't do GC,
your arm usage will skyrocket.
So they don't, they cannot put it too much,
but this is like already like,
how much was it?
1 gigabyte, that's the default.
And the problem is when you have 1 gigabyte
to garbage collect, it causes really long GC
time. So in GC image mode,
when you're actually using Emacs,
really heavily, the GCs become terrible,
terribly slow. So it may help in case you
don't have too much problems with GC,
but I will say that in such situation,
you can simply increase GC cost percentage,
as I recommend, and it should do it.
But in case of really big problems with
garbage collection, no,
I don't think that will help much.
I used it myself and it didn't help much for
my stuff.
[Speaker 0]: All right. The next question is concerning
freeing up memory. Is there some way to free
up memory such as via unload feature on
Emacs? Often I only need a package loaded for
a single task or short period by the
persistent memory afterwards.
[Speaker 1]: So the packages are usually not that much of
a problem. I mean, the libraries,
the problem is some extra,
like some variable contents or some
histories, some caches.
That's what's eating most of the memory.
There is a package called memory usage and
built in MX memory report.
They allow to see which variables take a lot
of memory. And that way you can try to see
which packages are actually problematic.
So for example, I recall,
and that was not exactly,
I remember there was a package that was
literally in command line,
like prompt history. I think it was in
command. And when you do like,
when you save every message in your chart
into prompt history, that can grow very fast
and can go to several hundred megabytes just
in that history. And that can cause major
problems. So, yes, profiling the largest
variables with the largest buffers that might
give some clues. Again,
there is no silver bullet.
[Speaker 0]: Right. I think the last question on the
patterns. At first, very nice presentation.
[Speaker 1]: I can
[Speaker 0]: also only agree with that.
I just experienced with a threshold and
lowered my GCE lapse from 1.1
to 0.06 seconds during startup.
Interestingly, going to 10 megabytes
increased the time. 4 megabytes was a sweet
spot for my system. What is the recommended
way to lower the value back to the default
value after startup is completed?
[Speaker 1]: I think you just use after init hook.
[Speaker 0]: This was a relatively fast answer.
[Speaker 1]: So basically for example Doom does this,
it temporary writes a gcconcert hold during
startup and yeah after init hook the code is
like it's 1 of the commonly suggested
approaches and is I believe it's the right 1.
[Speaker 0]: Right. To have joined us 1 was a microphone.
So Peter, do you have any questions that you
want to question? And maybe as a side note,
we only have 4 minutes left and afterwards
this happy weekend will still be open,
but we will switch back to the talks.
[Speaker 2]: Yeah, no more questions on garbage
collection, but I just wanted to thank Ihor
for his engagement in the community.
And especially with, I'm a co-maintainer on
orgnotor and he's helped us a lot with
getting us up to date with newer versions of
org and stuff like that.
So just wanted to thank you in person.
[Speaker 1]: Right.
[Speaker 0]: Maybe 1 question for me,
you had some bit talked about memory
fragmentation. So is there any way to or is
it fixed by Emacs itself?
So you have like
[Speaker 1]: a chunk of memory fragmentation is basically
your OS. Yeah, Emacs releases the memory and
then OS can rearrange it depending on the
implementation of its memory manager.
[Speaker 0]: Okay, so the GC just releases it really and
not so it could be that a mix is like
[Speaker 1]: doing it. You have like memory pages,
right? Yeah. And you see,
can release a part of this page just like
here and there. And depending on the exact
situation is your arm at each moment of time,
or as may or may not be able to arrange
[Speaker 0]: so
[Speaker 1]: things. So, how the exact the data you cannot
really predict it. It really varies like you
use Windows, you use Linux,
you use like malloc, something else,
but it has nothing to do with Emacs.
It's just something you have to deal with.
[Speaker 0]: Yeah, but my question was in the way that we
are giving the memory back to the operating
system, not just holding it as used and then
to our own memory, like stuff as Emacs that
we do not need to interact with the operating
[Speaker 1]: Yeah. Emacs does not really hold anything.
[Speaker 0]: system. That was the question.
[Speaker 1]: Okay. I was really hoping it does,
but yeah, unfortunately,
because nothing much can be done on Emacs.
[Speaker 0]: Okay. it's not Probably a lot faster if it's
just holding it and when it needs more,
then just get more from the OS.
[Speaker 1]: There are certain caveats,
for example, there's something called image
cache. And because Emacs stores images in
uncompressed format, it can occupy quite a
lot of memory. In particular,
when you will like view PDFs,
like you open 10, like 20 PDFs in 1 session,
you may have like some image cache blowing
up, But that's not common for people.
[Speaker 0]: So, guess we are on our time exactly.
So in the next
[Speaker 1]: I think I was not exactly accurate.
This 1 command, which is,
I think, Nemax 30, is called a malloc trim.
A max malloc trim. It's interactive.
So that can help to release some memory.
I think the way it works is like forces OS to
make use of the released memory.
[Speaker 0]: Okay. That would be like,
we are by the way, switch back to the next
talk. But
[Speaker 1]: so basically what happens here is that OS may
not release like, even Emacs says,
okay, this memory is free,
depending on the implementation,
I might think, okay, but I still hold that
memory associated with Emacs just in case
Emacs needs more memories,
and I can immediately put the data there
without like more arrangement to allocate
more. And this analog stream basically forces
the OS to release it, like no matter what.
[Speaker 0]: Because most people, when they are using
Emacs, I have the feeling they are only using
Emacs. So it would be kind of interesting if
you just take like, I don't know,
2 gigabytes or something of memory and Emacs
like does what it wants on that and the OS
cannot really take it back.
This was my idea when I
[Speaker 1]: was So when you see 2 gigabytes in OS,
it doesn't mean that OS cannot take it back.
It may still like allocate certain portion,
even technically free,
but just for future. So this is where Malloc
Dream works. It's like,
it says, yes, OS, I really not going to hold
this for this free memory.
For sure. If you try this MX Malloc Gene,
you will see like a few times to hundreds of
megabytes of read immediately.
[Speaker 0]: Have a look when I have the time.
[Speaker 1]: I
[Speaker 0]: guess if nobody has any questions,
I guess on the pad, there was Nothing else.
I guess we can just close it.
Thanks for the discussion.
Thanks for answering the questions.
[Speaker 1]: Thank you for the great conference.
And yeah, for your volunteer work.
And yeah, for quietly panicking in the
background, right? Yeah,
I mean... You have to be quiet,
you're panicking in the background.