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.
