path: root/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.vtt

WEBVTT


00:00:01.620 --> 00:00:02.120
[Speaker 0]: And then, hi everyone.

00:00:03.760 --> 00:00:04.150
Thank you for your nice talk,

00:00:05.900 --> 00:00:06.400
I can say it's the Emacs GC.

00:00:09.280 --> 00:00:09.519
We have some questions on the pad and maybe

00:00:11.580 --> 00:00:11.820
before I would like to ask you something to

00:00:12.780 --> 00:00:13.280
the last 1 you have said,

00:00:15.200 --> 00:00:15.700
concerning changing the GC strategy,

00:00:18.500 --> 00:00:18.840
that it's unlikely that it will be happening

00:00:20.380 --> 00:00:20.740
in the next time. Yeah.

00:00:22.760 --> 00:00:22.940
Is there any discussion going on or why does

00:00:24.320 --> 00:00:24.820
the case it's not changing the strategy?

00:00:26.640 --> 00:00:27.140
[Speaker 1]: It's mostly because it's difficult.

00:00:29.439 --> 00:00:29.860
I think, yesterday you heard from,

00:00:33.400 --> 00:00:33.900
1 of the dev talks that like there was 1

00:00:34.980 --> 00:00:35.220
small, short comment that,

00:00:36.780 --> 00:00:37.280
oh yeah, it would be nice to change this

00:00:39.059 --> 00:00:39.559
algorithm but it's hard.

00:00:40.760 --> 00:00:40.840
[Speaker 0]: So I

00:00:43.260 --> 00:00:43.700
[Speaker 1]: mean it's hard not because the algorithm is

00:00:45.400 --> 00:00:45.720
that hard but because it's a very low level

00:00:48.000 --> 00:00:48.500
code and it must be like very carefully

00:00:49.960 --> 00:00:50.460
weighted. So that can be,

00:00:53.239 --> 00:00:53.640
it needs to be made sure that the carousel

00:00:55.280 --> 00:00:55.780
will work. It's all bugs.

00:00:57.440 --> 00:00:57.600
If you have bugs and you can see that,

00:00:58.660 --> 00:00:59.160
so it's nothing to work anymore.

00:01:00.720 --> 00:01:01.200
[Speaker 0]: So We have a lot of RAM usage.

00:01:02.240 --> 00:01:02.740
Yeah. Maybe sometime.

00:01:06.180 --> 00:01:06.500
[Speaker 1]: There was like years ago,

00:01:09.640 --> 00:01:10.140
there was a branch on generational DC,

00:01:11.100 --> 00:01:11.600
if I remember correctly,

00:01:13.380 --> 00:01:13.880
but they didn't go anywhere,

00:01:14.760 --> 00:01:15.260
unfortunately.

00:01:18.900 --> 00:01:19.240
[Speaker 0]: That's a pity. But let's come to the

00:01:21.500 --> 00:01:22.000
questions on the pad. So the first 1 is,

00:01:24.340 --> 00:01:24.840
are the GC duration statistics correlated

00:01:27.340 --> 00:01:27.660
with users? I mean, does the same user

00:01:29.440 --> 00:01:29.940
experience GC of various durations?

00:01:32.900 --> 00:01:33.400
Or Do some users experience GC of a greater

00:01:36.680 --> 00:01:36.960
0.26 exclusively, while others never

00:01:40.440 --> 00:01:40.940
experience them? So is it correlated to user

00:01:43.780 --> 00:01:44.280
behavior? I guess you said it in your talk.

00:01:46.160 --> 00:01:46.660
[Speaker 1]: Well, If you talk formally,

00:01:49.340 --> 00:01:49.540
then almost every user has like 1 or 2

00:01:51.500 --> 00:01:52.000
occasions when GC takes more than 0.2

00:01:53.040 --> 00:01:53.540
seconds, but it's like,

00:01:56.720 --> 00:01:57.040
maybe something else is using CPU and that's

00:02:00.720 --> 00:02:00.920
why, but in practice, there are users who

00:02:04.200 --> 00:02:04.540
don't have problem. Half of them that that's

00:02:05.800 --> 00:02:06.300
who that's what I looked from statistics.

00:02:10.240 --> 00:02:10.440
And dry users who have like really big

00:02:12.520 --> 00:02:13.020
problems, like 1 second GC time.

00:02:17.280 --> 00:02:17.520
[Speaker 0]: This is dependent on you make some comments

00:02:19.960 --> 00:02:20.460
on us in the talk, but could you like extract

00:02:23.000 --> 00:02:23.200
on if it's a package, that's a problem or we

00:02:24.780 --> 00:02:25.280
as a user behavior are there.

00:02:30.720 --> 00:02:31.220
[Speaker 1]: Usually it's something that is,

00:02:33.760 --> 00:02:33.960
okay. I'm sharing my screen now,

00:02:37.580 --> 00:02:38.080
[Speaker 0]: It's coming on, give it like 2 to 3 seconds.

00:02:41.480 --> 00:02:41.980
[Speaker 1]: right? Yeah. So I can just click through

00:02:42.940 --> 00:02:43.440
different user statistics.

00:02:48.840 --> 00:02:49.080
So like you can see this duration for each

00:02:49.960 --> 00:02:50.460
individual user basically.

00:02:54.240 --> 00:02:54.740
So you can see like here for example it's

00:02:56.320 --> 00:02:56.820
like averages around 0.25

00:03:00.040 --> 00:03:00.420
seconds which is noticeable and here is like

00:03:03.640 --> 00:03:03.960
0.1 like someone is all over the place,

00:03:09.560 --> 00:03:10.060
probably some. Then like,

00:03:11.520 --> 00:03:12.020
what else can we see here?

00:03:15.140 --> 00:03:15.640
Yeah, some users like have sub 0.1,

00:03:23.320 --> 00:03:23.560
no problem at all. And I have seen some that

00:03:30.180 --> 00:03:30.240
really, really bad. I mean,

00:03:31.880 --> 00:03:32.240
[Speaker 0]: if it's noticeable, it's all bad.

00:03:36.960 --> 00:03:37.460
[Speaker 1]: So yeah. For example, here it's like 0.8

00:03:41.680 --> 00:03:42.040
seconds, 0.5 seconds. I don't know how that

00:03:48.600 --> 00:03:49.100
guy uses ZMax. Yeah. you can see it varies.

00:03:51.160 --> 00:03:51.660
[Speaker 0]: So It varies quite a lot.

00:03:52.760 --> 00:03:53.000
[Speaker 1]: What it depends on, like,

00:03:54.120 --> 00:03:54.620
usually the number of packages,

00:03:58.440 --> 00:03:58.620
like all kinds of timers going on under the

00:04:01.720 --> 00:04:02.220
hood. I think I tried to list...

00:04:12.520 --> 00:04:12.800
I'll go through this. I briefly outlined some

00:04:15.440 --> 00:04:15.940
important parts. Here,

00:04:18.480 --> 00:04:18.980
when you have something like an org agenda,

00:04:20.680 --> 00:04:21.180
it will most likely trigger a lot of GCs.

00:04:23.900 --> 00:04:24.400
When you have a lot of timers,

00:04:27.800 --> 00:04:27.980
when you have something calculated on

00:04:29.700 --> 00:04:30.200
modline, it will be frequently triggered.

00:04:30.900 --> 00:04:31.240
[Speaker 0]: Well,

00:04:34.080 --> 00:04:34.260
[Speaker 1]: yeah. When you have so many packages and

00:04:35.760 --> 00:04:36.260
these packages are using a lot of memory.

00:04:41.120 --> 00:04:41.540
Like I remember I was surprised by this,

00:04:44.640 --> 00:04:45.020
package, home org that was,

00:04:46.560 --> 00:04:47.060
caching all the results.

00:04:48.960 --> 00:04:49.280
And for large org files,

00:04:51.540 --> 00:04:51.720
it was like several hundred megabytes of

00:04:55.160 --> 00:04:55.660
data. Well, it just becomes slower.

00:04:55.900 --> 00:04:56.280
Yeah.

00:05:00.020 --> 00:05:00.340
[Speaker 0]: Yeah. Maybe, maybe a short side note.

00:05:02.600 --> 00:05:02.760
Someone asks, what software you're using for

00:05:03.480 --> 00:05:03.980
flipping through the PNGs.

00:05:06.660 --> 00:05:07.160
Maybe you could shortly throws it in.

00:05:08.800 --> 00:05:09.280
[Speaker 1]: What do you mean? Here,

00:05:11.000 --> 00:05:11.500
[Speaker 0]: I guess it was just simply,

00:05:13.480 --> 00:05:13.980
[Speaker 1]: this, It's it's far. Yeah.

00:05:16.660 --> 00:05:17.160
So

00:05:23.900 --> 00:05:24.400
[Speaker 0]: yeah. So, question 1 and 2 answered.

00:05:35.740 --> 00:05:36.040
To 1 statement you have made,

00:05:37.500 --> 00:05:38.000
there was a question concerning the timings.

00:05:41.180 --> 00:05:41.680
So you said, okay, everything above 0.1

00:05:45.800 --> 00:05:46.120
second is fine. Maybe There's a short story

00:05:48.480 --> 00:05:48.980
of someone who asked a question.

00:05:50.380 --> 00:05:50.800
[Speaker 1]: I see the question is about scrolling,

00:05:51.820 --> 00:05:52.320
[Speaker 0]: Yeah, exactly.

00:05:55.580 --> 00:05:55.760
[Speaker 1]: right? Again, there's not much you can do in

00:05:58.620 --> 00:05:58.860
terms of trying to adjust the GC time.

00:06:02.320 --> 00:06:02.820
I mean, if you make GCs less frequent,

00:06:07.540 --> 00:06:08.000
you increase the individual GC time.

00:06:08.860 --> 00:06:09.280
If you make them more frequent,

00:06:11.280 --> 00:06:11.520
you decrease the individual GC time,

00:06:12.400 --> 00:06:12.740
but then they are more frequent.

00:06:15.920 --> 00:06:16.200
So what is the point? I think the way to go

00:06:19.940 --> 00:06:20.080
here is you can rise to see the short for the

00:06:20.740 --> 00:06:21.240
duration of scrolling,

00:06:22.500 --> 00:06:22.860
like just for a comment.

00:06:26.320 --> 00:06:26.740
I think it's a recommendation from Emacs

00:06:31.480 --> 00:06:31.660
devs. So like You do something along the

00:06:31.660 --> 00:06:32.160
lines.

00:06:53.480 --> 00:06:53.800
Yeah, I'm surely doing something on my screen

00:06:55.680 --> 00:06:56.180
and I forgot that I'm not sharing anything.

00:06:56.680 --> 00:06:57.180
[Speaker 0]: Exactly.

00:07:00.700 --> 00:07:01.200
[Speaker 1]: Simply something like this.

00:07:08.140 --> 00:07:08.460
So, basically, if you have some command that

00:07:10.920 --> 00:07:11.180
is very important that it should run very

00:07:13.860 --> 00:07:14.120
quickly. You temporary increase that

00:07:15.740 --> 00:07:16.240
threshold, you run that comment,

00:07:19.940 --> 00:07:20.140
then that's all. That's probably the best.

00:07:21.660 --> 00:07:22.000
So basically, the best you can do is to delay

00:07:23.760 --> 00:07:24.260
it after the command.

00:07:27.500 --> 00:07:27.700
[Speaker 0]: So afterwards, it takes a lot of time to do

00:07:36.140 --> 00:07:36.500
its stuff. OK. The third 1 has been already

00:07:40.520 --> 00:07:40.780
answered, but I just want to get your

00:07:42.780 --> 00:07:43.280
information from it. Opinions on the GCMH

00:07:43.940 --> 00:07:44.440
mode.

00:07:48.280 --> 00:07:48.640
[Speaker 1]: Okay. Yeah, I see that problem,

00:07:49.920 --> 00:07:50.420
but that's more like a technical problem.

00:07:52.360 --> 00:07:52.860
But there's another problem there.

00:07:57.340 --> 00:07:57.840
Yeah, I prepared a small snippet here.

00:08:02.160 --> 00:08:02.660
So if you look at the GCMH mode,

00:08:05.800 --> 00:08:06.040
it has this concept of low threshold and high

00:08:08.200 --> 00:08:08.560
threshold and most of the time it's running

00:08:14.120 --> 00:08:14.620
high threshold and then when Emacs is idle,

00:08:17.320 --> 00:08:17.480
it falls back to lower threshold and then it

00:08:19.400 --> 00:08:19.900
does the GC while Emacs is not used.

00:08:22.040 --> 00:08:22.360
That's a good idea, of course.

00:08:24.380 --> 00:08:24.880
That's the core idea of GCMH mode.

00:08:30.520 --> 00:08:30.720
Unfortunately, the most annoying GC is when

00:08:31.760 --> 00:08:32.260
you're actively using max.

00:08:37.120 --> 00:08:37.419
And then you have this huge value of GC

00:08:38.799 --> 00:08:39.299
counter show and look at the doc stream.

00:08:41.760 --> 00:08:42.080
This would be sector value that makes GC

00:08:43.980 --> 00:08:44.480
unlikely but does not cost OSP Asian.

00:08:46.480 --> 00:08:46.880
So yeah, no wonder like if you don't do GC,

00:08:49.640 --> 00:08:50.140
your arm usage will skyrocket.

00:08:54.360 --> 00:08:54.860
So they don't, they cannot put it too much,

00:08:57.720 --> 00:08:58.220
but this is like already like,

00:08:59.220 --> 00:08:59.720
how much was it?

00:09:10.800 --> 00:09:10.860
1 gigabyte, that's the default.

00:09:15.220 --> 00:09:15.720
And the problem is when you have 1 gigabyte

00:09:18.680 --> 00:09:19.000
to garbage collect, it causes really long GC

00:09:22.040 --> 00:09:22.480
time. So in GC image mode,

00:09:23.560 --> 00:09:24.060
when you're actually using Emacs,

00:09:28.860 --> 00:09:29.360
really heavily, the GCs become terrible,

00:09:34.640 --> 00:09:34.860
terribly slow. So it may help in case you

00:09:37.200 --> 00:09:37.540
don't have too much problems with GC,

00:09:39.280 --> 00:09:39.720
but I will say that in such situation,

00:09:41.920 --> 00:09:42.420
you can simply increase GC cost percentage,

00:09:44.540 --> 00:09:45.040
as I recommend, and it should do it.

00:09:48.480 --> 00:09:48.640
But in case of really big problems with

00:09:50.080 --> 00:09:50.540
garbage collection, no,

00:09:51.740 --> 00:09:52.240
I don't think that will help much.

00:09:54.800 --> 00:09:54.960
I used it myself and it didn't help much for

00:09:55.200 --> 00:09:55.700
my stuff.

00:09:59.680 --> 00:10:00.180
[Speaker 0]: All right. The next question is concerning

00:10:04.600 --> 00:10:04.820
freeing up memory. Is there some way to free

00:10:07.200 --> 00:10:07.420
up memory such as via unload feature on

00:10:09.960 --> 00:10:10.120
Emacs? Often I only need a package loaded for

00:10:12.240 --> 00:10:12.400
a single task or short period by the

00:10:13.320 --> 00:10:13.820
persistent memory afterwards.

00:10:19.780 --> 00:10:19.940
[Speaker 1]: So the packages are usually not that much of

00:10:22.060 --> 00:10:22.560
a problem. I mean, the libraries,

00:10:25.280 --> 00:10:25.780
the problem is some extra,

00:10:30.060 --> 00:10:30.340
like some variable contents or some

00:10:31.800 --> 00:10:32.300
histories, some caches.

00:10:35.280 --> 00:10:35.780
That's what's eating most of the memory.

00:10:40.240 --> 00:10:40.740
There is a package called memory usage and

00:10:45.440 --> 00:10:45.940
built in MX memory report.

00:10:50.900 --> 00:10:51.100
They allow to see which variables take a lot

00:10:56.000 --> 00:10:56.500
of memory. And that way you can try to see

00:10:58.520 --> 00:10:59.020
which packages are actually problematic.

00:11:03.340 --> 00:11:03.840
So for example, I recall,

00:11:05.640 --> 00:11:06.140
and that was not exactly,

00:11:09.720 --> 00:11:09.880
I remember there was a package that was

00:11:11.040 --> 00:11:11.260
literally in command line,

00:11:14.020 --> 00:11:14.240
like prompt history. I think it was in

00:11:17.540 --> 00:11:18.040
command. And when you do like,

00:11:20.440 --> 00:11:20.940
when you save every message in your chart

00:11:25.280 --> 00:11:25.780
into prompt history, that can grow very fast

00:11:29.220 --> 00:11:29.600
and can go to several hundred megabytes just

00:11:31.720 --> 00:11:32.020
in that history. And that can cause major

00:11:37.960 --> 00:11:38.360
problems. So, yes, profiling the largest

00:11:41.200 --> 00:11:41.600
variables with the largest buffers that might

00:11:42.660 --> 00:11:42.900
give some clues. Again,

00:11:43.740 --> 00:11:44.240
there is no silver bullet.

00:11:49.080 --> 00:11:49.320
[Speaker 0]: Right. I think the last question on the

00:11:51.000 --> 00:11:51.500
patterns. At first, very nice presentation.

00:11:51.620 --> 00:11:51.780
[Speaker 1]: I can

00:11:53.980 --> 00:11:54.480
[Speaker 0]: also only agree with that.

00:11:56.480 --> 00:11:56.640
I just experienced with a threshold and

00:11:58.200 --> 00:11:58.700
lowered my GCE lapse from 1.1

00:12:01.440 --> 00:12:01.940
to 0.06 seconds during startup.

00:12:03.600 --> 00:12:04.100
Interestingly, going to 10 megabytes

00:12:06.100 --> 00:12:06.340
increased the time. 4 megabytes was a sweet

00:12:07.800 --> 00:12:08.300
spot for my system. What is the recommended

00:12:10.840 --> 00:12:11.260
way to lower the value back to the default

00:12:12.340 --> 00:12:12.840
value after startup is completed?

00:12:16.160 --> 00:12:16.660
[Speaker 1]: I think you just use after init hook.

00:12:23.940 --> 00:12:24.440
[Speaker 0]: This was a relatively fast answer.

00:12:29.180 --> 00:12:29.480
[Speaker 1]: So basically for example Doom does this,

00:12:31.940 --> 00:12:32.220
it temporary writes a gcconcert hold during

00:12:37.260 --> 00:12:37.760
startup and yeah after init hook the code is

00:12:39.880 --> 00:12:40.380
like it's 1 of the commonly suggested

00:12:43.940 --> 00:12:44.440
approaches and is I believe it's the right 1.

00:12:49.180 --> 00:12:49.680
[Speaker 0]: Right. To have joined us 1 was a microphone.

00:12:52.200 --> 00:12:52.360
So Peter, do you have any questions that you

00:12:55.240 --> 00:12:55.640
want to question? And maybe as a side note,

00:12:57.380 --> 00:12:57.740
we only have 4 minutes left and afterwards

00:12:59.240 --> 00:12:59.480
this happy weekend will still be open,

00:13:01.400 --> 00:13:01.900
but we will switch back to the talks.

00:13:05.380 --> 00:13:05.820
[Speaker 2]: Yeah, no more questions on garbage

00:13:07.640 --> 00:13:08.140
collection, but I just wanted to thank Ihor

00:13:10.440 --> 00:13:10.940
for his engagement in the community.

00:13:15.300 --> 00:13:15.480
And especially with, I'm a co-maintainer on

00:13:17.600 --> 00:13:18.100
orgnotor and he's helped us a lot with

00:13:21.680 --> 00:13:21.820
getting us up to date with newer versions of

00:13:22.680 --> 00:13:22.960
org and stuff like that.

00:13:24.680 --> 00:13:25.140
So just wanted to thank you in person.

00:13:25.140 --> 00:13:25.640
[Speaker 1]: Right.

00:13:33.540 --> 00:13:33.800
[Speaker 0]: Maybe 1 question for me,

00:13:35.460 --> 00:13:35.760
you had some bit talked about memory

00:13:40.640 --> 00:13:40.800
fragmentation. So is there any way to or is

00:13:42.080 --> 00:13:42.580
it fixed by Emacs itself?

00:13:43.740 --> 00:13:43.940
So you have like

00:13:46.520 --> 00:13:46.980
[Speaker 1]: a chunk of memory fragmentation is basically

00:13:51.420 --> 00:13:51.600
your OS. Yeah, Emacs releases the memory and

00:13:55.020 --> 00:13:55.200
then OS can rearrange it depending on the

00:13:58.320 --> 00:13:58.820
implementation of its memory manager.

00:14:01.520 --> 00:14:01.720
[Speaker 0]: Okay, so the GC just releases it really and

00:14:04.400 --> 00:14:04.900
not so it could be that a mix is like

00:14:07.420 --> 00:14:07.840
[Speaker 1]: doing it. You have like memory pages,

00:14:09.560 --> 00:14:09.760
right? Yeah. And you see,

00:14:12.140 --> 00:14:12.600
can release a part of this page just like

00:14:14.760 --> 00:14:15.060
here and there. And depending on the exact

00:14:17.720 --> 00:14:18.220
situation is your arm at each moment of time,

00:14:20.240 --> 00:14:20.640
or as may or may not be able to arrange

00:14:25.160 --> 00:14:25.640
[Speaker 0]: so

00:14:27.620 --> 00:14:27.940
[Speaker 1]: things. So, how the exact the data you cannot

00:14:30.160 --> 00:14:30.320
really predict it. It really varies like you

00:14:31.120 --> 00:14:31.480
use Windows, you use Linux,

00:14:33.240 --> 00:14:33.740
you use like malloc, something else,

00:14:36.260 --> 00:14:36.600
but it has nothing to do with Emacs.

00:14:38.040 --> 00:14:38.540
It's just something you have to deal with.

00:14:41.780 --> 00:14:41.940
[Speaker 0]: Yeah, but my question was in the way that we

00:14:43.460 --> 00:14:43.860
are giving the memory back to the operating

00:14:46.020 --> 00:14:46.440
system, not just holding it as used and then

00:14:49.960 --> 00:14:50.140
to our own memory, like stuff as Emacs that

00:14:51.680 --> 00:14:52.120
we do not need to interact with the operating

00:14:56.040 --> 00:14:56.540
[Speaker 1]: Yeah. Emacs does not really hold anything.

00:14:59.160 --> 00:14:59.580
[Speaker 0]: system. That was the question.

00:15:01.920 --> 00:15:02.220
[Speaker 1]: Okay. I was really hoping it does,

00:15:02.760 --> 00:15:03.260
but yeah, unfortunately,

00:15:05.640 --> 00:15:06.140
because nothing much can be done on Emacs.

00:15:08.800 --> 00:15:08.940
[Speaker 0]: Okay. it's not Probably a lot faster if it's

00:15:10.580 --> 00:15:10.800
just holding it and when it needs more,

00:15:12.380 --> 00:15:12.880
then just get more from the OS.

00:15:14.220 --> 00:15:14.620
[Speaker 1]: There are certain caveats,

00:15:16.720 --> 00:15:17.220
for example, there's something called image

00:15:20.560 --> 00:15:20.740
cache. And because Emacs stores images in

00:15:23.720 --> 00:15:23.800
uncompressed format, it can occupy quite a

00:15:25.020 --> 00:15:25.320
lot of memory. In particular,

00:15:26.520 --> 00:15:27.020
when you will like view PDFs,

00:15:30.140 --> 00:15:30.640
like you open 10, like 20 PDFs in 1 session,

00:15:33.460 --> 00:15:33.820
you may have like some image cache blowing

00:15:36.720 --> 00:15:37.220
up, But that's not common for people.

00:15:41.420 --> 00:15:41.920
[Speaker 0]: So, guess we are on our time exactly.

00:15:43.580 --> 00:15:44.080
So in the next

00:15:46.680 --> 00:15:47.180
[Speaker 1]: I think I was not exactly accurate.

00:15:49.200 --> 00:15:49.640
This 1 command, which is,

00:15:53.500 --> 00:15:54.000
I think, Nemax 30, is called a malloc trim.

00:15:57.520 --> 00:15:58.020
A max malloc trim. It's interactive.

00:16:04.080 --> 00:16:04.580
So that can help to release some memory.

00:16:08.200 --> 00:16:08.700
I think the way it works is like forces OS to

00:16:12.040 --> 00:16:12.540
make use of the released memory.

00:16:14.960 --> 00:16:15.460
[Speaker 0]: Okay. That would be like,

00:16:18.420 --> 00:16:18.640
we are by the way, switch back to the next

00:16:21.420 --> 00:16:21.680
talk. But

00:16:24.220 --> 00:16:24.400
[Speaker 1]: so basically what happens here is that OS may

00:16:27.440 --> 00:16:27.720
not release like, even Emacs says,

00:16:28.740 --> 00:16:29.240
okay, this memory is free,

00:16:30.060 --> 00:16:30.560
depending on the implementation,

00:16:32.760 --> 00:16:32.980
I might think, okay, but I still hold that

00:16:34.860 --> 00:16:35.080
memory associated with Emacs just in case

00:16:35.800 --> 00:16:36.180
Emacs needs more memories,

00:16:38.940 --> 00:16:39.180
and I can immediately put the data there

00:16:41.420 --> 00:16:41.920
without like more arrangement to allocate

00:16:45.480 --> 00:16:45.980
more. And this analog stream basically forces

00:16:48.740 --> 00:16:49.240
the OS to release it, like no matter what.

00:16:52.360 --> 00:16:52.860
[Speaker 0]: Because most people, when they are using

00:16:54.320 --> 00:16:54.620
Emacs, I have the feeling they are only using

00:16:56.160 --> 00:16:56.480
Emacs. So it would be kind of interesting if

00:16:57.880 --> 00:16:58.140
you just take like, I don't know,

00:17:00.060 --> 00:17:00.560
2 gigabytes or something of memory and Emacs

00:17:02.900 --> 00:17:03.160
like does what it wants on that and the OS

00:17:04.079 --> 00:17:04.540
cannot really take it back.

00:17:05.920 --> 00:17:06.040
This was my idea when I

00:17:08.000 --> 00:17:08.319
[Speaker 1]: was So when you see 2 gigabytes in OS,

00:17:10.359 --> 00:17:10.859
it doesn't mean that OS cannot take it back.

00:17:13.859 --> 00:17:14.359
It may still like allocate certain portion,

00:17:15.640 --> 00:17:16.140
even technically free,

00:17:20.940 --> 00:17:21.319
but just for future. So this is where Malloc

00:17:22.339 --> 00:17:22.579
Dream works. It's like,

00:17:25.319 --> 00:17:25.540
it says, yes, OS, I really not going to hold

00:17:26.500 --> 00:17:27.000
this for this free memory.

00:17:31.700 --> 00:17:31.860
For sure. If you try this MX Malloc Gene,

00:17:33.960 --> 00:17:34.140
you will see like a few times to hundreds of

00:17:35.200 --> 00:17:35.700
megabytes of read immediately.

00:17:38.560 --> 00:17:39.060
[Speaker 0]: Have a look when I have the time.

00:17:41.480 --> 00:17:41.600
[Speaker 1]: I

00:17:43.260 --> 00:17:43.680
[Speaker 0]: guess if nobody has any questions,

00:17:45.660 --> 00:17:46.160
I guess on the pad, there was Nothing else.

00:17:47.900 --> 00:17:48.340
I guess we can just close it.

00:17:49.140 --> 00:17:49.600
Thanks for the discussion.

00:17:50.640 --> 00:17:51.140
Thanks for answering the questions.

00:17:56.020 --> 00:17:56.520
[Speaker 1]: Thank you for the great conference.

00:17:59.340 --> 00:17:59.840
And yeah, for your volunteer work.

00:18:02.230 --> 00:18:02.241
And yeah, for quietly panicking in the

00:18:02.262 --> 00:18:02.273
background, right? Yeah,

00:18:02.337 --> 00:18:02.348
I mean... You have to be quiet,

00:18:02.560 --> 00:18:03.060
you're panicking in the background.