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.