summaryrefslogtreecommitdiffstats
path: root/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.vtt
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.vtt1049
1 files changed, 1049 insertions, 0 deletions
diff --git a/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.vtt b/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.vtt
new file mode 100644
index 00000000..71a15554
--- /dev/null
+++ b/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.vtt
@@ -0,0 +1,1049 @@
+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.