diff options
Diffstat (limited to '2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.vtt')
| -rw-r--r-- | 2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.vtt | 1049 |
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. |