more markers

11 files changed, 2175 insertions, 571 deletions

diff --git a/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt b/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt
index c1bea8de..d1e2a5f6 100644
--- a/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt
+++ b/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt
@@ -1,848 +1,1780 @@
-WEBVTT
+WEBVTT captioned by sachac
 
-00:00.000 --> 00:06.480
-Hello everyone, my name is Igor Achinko and you may know me from Org Mailing List.
+NOTE Introduction
 
-00:07.440 --> 00:11.760
-However, today I'm not going to talk about Org Mode. Today I'm going to talk about
+00:00:00.000 --> 00:00:04.639
+Hello everyone, my name is Ihor Radchenko,
 
-00:11.760 --> 00:16.800
-Emacs performance and how it's affected by its memory management code.
+00:00:04.640 --> 00:00:07.599
+and you may know me from Org Mailing List.
 
-00:18.880 --> 00:24.720
-First, I will introduce the basic concepts of Emacs memory management and what garbage
+00:00:07.600 --> 00:00:09.799
+However, today I'm not going to talk about Org Mode.
 
-00:24.720 --> 00:32.320
-collection is. Then I will show you user statistics collected from volunteer users
+00:00:09.800 --> 00:00:11.919
+Today I'm going to talk about
 
-00:32.320 --> 00:42.080
-over the last half year and I will end with some guidelines on how to tweak Emacs garbage
+00:00:11.920 --> 00:00:14.959
+Emacs performance and how it's affected
 
-00:42.080 --> 00:48.640
-collection customizations to optimize Emacs performance and when it's necessary or not
+00:00:14.960 --> 00:00:19.039
+by its memory management code.
 
-00:49.120 --> 00:56.560
-to do. Let's begin. What is garbage collection? To understand what is garbage collection we need
+00:00:19.040 --> 00:00:21.639
+First, I will introduce the basic concepts
 
-00:56.560 --> 01:01.920
-to realize that anything you do in Emacs is some kind of command and any command is most likely
+00:00:21.640 --> 00:00:26.439
+of Emacs memory management and what garbage collection is.
 
-01:01.920 --> 01:07.280
-running some Elisp code and every time you run Elisp code you most likely need to locate certain
+00:00:26.440 --> 00:00:30.559
+Then I will show you user statistics
 
-01:07.280 --> 01:14.160
-memory in RAM and some of this memory is retained for a long time and some of this memory is
+00:00:30.560 --> 00:00:34.959
+collected from volunteer users over the last half year
 
-01:14.160 --> 01:20.320
-transient. Of course, Emacs has to clear this transient memory from time to time to not occupy
+00:00:34.960 --> 00:00:39.319
+and I will end with some guidelines
 
-01:20.320 --> 01:27.200
-all the possible RAM in the computer. In this small example we have one global variable
+00:00:39.320 --> 00:00:44.719
+on how to tweak Emacs garbage collection customizations
 
-01:28.480 --> 01:35.600
-that is assigned a value but when assigning the value we first allocate a temporary variable
+00:00:44.720 --> 00:00:47.479
+to optimize Emacs performance
 
-01:35.600 --> 01:41.360
-and then a temporary list and only retain some part of this list in this global variable.
+00:00:47.480 --> 00:00:51.079
+and when it's necessary or not to do.
 
-01:42.240 --> 01:51.920
-In terms of memory graph we can represent this as two variable slots, one transient, one permanent
+NOTE About garbage collection in Emacs
 
-01:52.480 --> 02:01.680
-and then a list of three concerns and part of which is retained as a global variable but part
+00:00:51.080 --> 00:00:54.519
+Let's begin. What is garbage collection?
 
-02:01.680 --> 02:07.280
-of it which is a temporary variable symbol and the first term of the list is not used and it
+00:00:54.520 --> 00:00:56.519
+To understand what is garbage collection,
 
-02:07.840 --> 02:15.040
-might be cleared at some point. So that's what Emacs does. Every now and then Emacs goes through
+00:00:56.520 --> 00:00:59.039
+we need to realize that anything you do in Emacs
 
-02:15.040 --> 02:20.320
-all the memory and identify which part of the memory are not used and then clear them so that
+00:00:59.040 --> 00:01:02.119
+is some kind of command. Any command is most likely
 
-02:20.320 --> 02:27.760
-it can free up the RAM. This process is called garbage collection and Emacs uses a very simple
+00:01:02.120 --> 00:01:05.839
+running some Elisp code. Every time you run Elisp code,
 
-02:27.760 --> 02:33.440
-and old algorithm which is called mark and sweep. So during this mark and sweep process
+00:01:05.840 --> 00:01:09.239
+you most likely need to locate certain memory in RAM.
 
-02:33.440 --> 02:40.880
-is basically two stages. First Emacs scans all the memory that is allocated and then identify
+00:01:09.240 --> 00:01:12.879
+Some of this memory is retained for a long time
 
-02:40.880 --> 02:46.320
-which memory is still in use which is linked to some variables for example and which memory is
+00:01:12.880 --> 00:01:15.559
+and some of this memory is transient.
 
-02:46.320 --> 02:51.600
-not used anymore even though it was allocated in the past and the second stage is clear that
+00:01:15.560 --> 00:01:19.119
+Of course, Emacs has to clear this transient memory
 
-02:51.600 --> 02:56.240
-whatever a memory is not that is not allocated. During the process
+00:01:19.120 --> 00:01:21.439
+from time to time, to not occupy all the possible RAM
 
-02:56.880 --> 03:03.920
-Emacs cannot do anything now. So basically every time Emacs scans the memory it freezes up and
+00:01:21.440 --> 00:01:21.447
+in the computer. In this small example,
 
-03:03.920 --> 03:09.840
-doesn't respond to anything and if it takes too much time so that users can notice it then of
+00:01:21.448 --> 00:01:28.639
+we have one global variable
 
-03:09.840 --> 03:18.160
-course Emacs is not responsive at all and if this garbage collection is triggered too frequently
+00:01:28.640 --> 00:01:31.279
+that is assigned a value,
 
-03:18.160 --> 03:23.760
-then it's not just not responsive every now and then it's also not responsive all the time almost
+00:01:31.280 --> 00:01:33.079
+but when assigning the value,
 
-03:24.000 --> 03:29.840
-all the time so it cannot even normally type or stuff or do some normal commands.
+00:01:33.080 --> 00:01:35.679
+we first allocate a temporary variable
 
-03:32.320 --> 03:40.080
-This mark and sweep algorithm is taking longer the more memory Emacs uses. So basically
+00:01:35.680 --> 00:01:37.119
+and then a temporary list
 
-03:40.080 --> 03:46.480
-the more buffers you open, the more packages you load, the more complex commands you run,
+00:01:37.120 --> 00:01:40.079
+and only retain some part of this list
 
-03:46.480 --> 03:55.840
-the more memory is used and basically the longer Emacs takes to perform a single garbage collection.
+00:01:40.080 --> 00:01:42.079
+in this global variable.
 
-04:00.560 --> 04:07.280
-Of course Emacs being Emacs and this garbage collection can be tweaked. In particular
+00:01:42.080 --> 00:01:44.799
+In terms of memory graph
 
-04:07.280 --> 04:12.960
-users can tweak how frequently Emacs does garbage collection using two basic variables
+00:01:44.800 --> 00:01:50.359
+we can represent this as two variable slots,
 
-04:12.960 --> 04:19.840
-GCConsThreshold and GCConsPercentage. GCConsThreshold is the raw number of kilobytes
+00:01:50.360 --> 00:01:53.159
+one transient, one permanent,
 
-04:21.440 --> 04:27.200
-Emacs needs to allocate before triggering another garbage collection and the GCConsPercentage
+00:01:53.160 --> 00:01:56.199
+and then a list of three cons cells,
 
-04:27.200 --> 04:31.680
-is similar but it's defined in terms of fraction of already allocated memory.
+00:01:56.200 --> 00:02:01.959
+part of which is retained as a global variable
 
-04:33.840 --> 04:41.840
-If you follow various Emacs forums you may be familiar with people complaining about
+00:02:01.960 --> 00:02:04.999
+but part of it which is a temporary variable symbol.
 
-04:41.840 --> 04:47.760
-garbage collection and there are many many suggestions about what to do with it.
+00:02:05.000 --> 00:02:07.679
+The first term of the list is not used
 
-04:50.320 --> 04:52.640
-Most frequently you see GCConsThreshold
+00:02:07.680 --> 00:02:09.759
+and it might be cleared at some point.
 
-04:54.640 --> 05:01.280
-recommended to be increased and a number of pre-packaged Emacs distributions like
+NOTE Garbage collection in Emacs
 
-05:01.280 --> 05:07.280
-DoMeEmacs do increase it or like I have seen suggestions which are actually horrible to
+00:02:09.760 --> 00:02:12.239
+So that's what Emacs does.
 
-05:07.280 --> 05:11.120
-disable garbage collection temporarily or for a long time.
+00:02:12.240 --> 00:02:15.919
+Every now and then, Emacs goes through all the memory
 
-05:14.240 --> 05:19.600
-Which is nice you can see it quite frequently which indicates there might be some problem.
+00:02:15.920 --> 00:02:19.119
+and identifies which part of the memory are not used
 
-05:19.600 --> 05:26.320
-However every time like one user poses about this problem it's just one data point and it doesn't
+00:02:19.120 --> 00:02:23.759
+and then clear them so that it can free up the RAM.
 
-05:26.320 --> 05:30.000
-mean that everyone actually suffers from it. It doesn't mean that everyone should do it.
+00:02:23.760 --> 00:02:25.919
+This process is called garbage collection
 
-05:30.720 --> 05:37.680
-So in order to understand if this garbage collection is really a problem which is a
+00:02:25.920 --> 00:02:28.919
+and Emacs uses a very simple and old algorithm
 
-05:37.680 --> 05:48.000
-common problem we do need some kind of statistics and only using the actual statistics we can
+00:02:28.920 --> 00:02:30.559
+which is called Mark & Sweep.
 
-05:48.000 --> 05:54.880
-understand if it should be recommended for everyone to tweak the defaults or like whether
+00:02:30.560 --> 00:02:33.759
+So doing this mark and sweep process
 
-05:54.880 --> 06:00.000
-it should be recommended for certain users or maybe it should be asked Emacs devs to do
+00:02:33.760 --> 00:02:34.879
+is basically two stages.
 
-06:00.000 --> 06:08.800
-something about the defaults. And what I did some time ago is exactly this. I tried to collect the
+00:02:34.880 --> 00:02:40.039
+First, Emacs scans all the memory that is allocated
 
-06:08.800 --> 06:18.000
-user statistics. So I wrote a small package on Elp and some users installed this package and
+00:02:40.040 --> 00:02:42.759
+and then identifies which memory is still in use
 
-06:18.000 --> 06:24.080
-then reported back these statistics of the garbage collection for their particular use.
+00:02:42.760 --> 00:02:45.519
+which is linked to some variables, for example,
 
-06:25.360 --> 06:33.840
-By now we have obtained 129 user submissions with over 1 million GC records in there.
+00:02:45.520 --> 00:02:47.599
+and which memory is not used anymore
 
-06:35.760 --> 06:42.320
-So like some of these submissions used default GC settings without any customizations.
+00:02:47.600 --> 00:02:49.559
+even though it was allocated in the past.
 
-06:42.320 --> 06:47.040
-Some used increased GC cost threshold and GC cost percentage.
+00:02:49.560 --> 00:02:52.999
+The second stage [??] whenever a memory is not,
 
-06:48.880 --> 06:56.640
-So using this data we can try to draw some reliable conclusions on what should be done
+00:02:53.000 --> 00:02:59.319
+that is not allocated. During the process
 
-06:56.640 --> 07:02.480
-and whether should anything be done about garbage collection on Emacs dev level or at least on user
+00:02:59.320 --> 00:03:00.759
+Emacs cannot do anything now.
 
-07:02.480 --> 07:08.240
-level. Of course we need to keep in mind that there's some kind of bias because it's more
+00:03:00.760 --> 00:03:04.159
+So basically, every time Emacs scans the memory,
 
-07:08.240 --> 07:13.680
-likely that users already have problems with GC or they think they have problems with GC will report
+00:03:04.160 --> 00:03:07.199
+it freezes up and doesn't respond to anything,
 
-07:14.480 --> 07:20.240
-and submit the data. But anyway having s statistics is much more useful than just
+00:03:07.200 --> 00:03:10.959
+and if it takes too much time so that users can notice it,
 
-07:20.240 --> 07:28.240
-having anecdotal evidences from one or other reddit posts. And just one thing I will do
+00:03:10.960 --> 00:03:13.399
+then of course Emacs is not responsive at all,
 
-07:28.880 --> 07:33.280
-during the rest of my presentation is that for all the statistics I will normalize
+00:03:13.400 --> 00:03:19.439
+and if this garbage collection is triggered too frequently,
 
-07:33.520 --> 07:41.440
-user data so that every user contributes equally. For example if one user submits like 100 hours
+00:03:19.440 --> 00:03:22.399
+then it's not just not responsive every now and then.
 
-07:41.440 --> 07:46.640
-Emacs uptime statistics and other users submit one hour Emacs uptime then I will
+00:03:22.400 --> 00:03:24.679
+It's also not responsive all the time,
 
-07:47.200 --> 07:49.520
-anyway make it so that they contribute equally.
+00:03:24.680 --> 00:03:26.079
+almost all the time,
 
-07:53.280 --> 07:59.280
-Let's start from one of the most obvious things we can look into is which is the time it takes
+00:03:26.080 --> 00:03:27.679
+so it cannot even normally type or stuff
 
-07:59.360 --> 08:05.520
-for garbage collection to single garbage collection process. Here you see
+00:03:27.680 --> 00:03:32.439
+or do some normal commands.
 
-08:08.240 --> 08:16.240
-frequency distribution of GC duration for all the 129 users we got and
+00:03:32.440 --> 00:03:36.719
+This mark and sweep algorithm is taking longer
 
-08:17.600 --> 08:26.800
-you can see that most of the garbage collections are done quite quickly in less than 0.1 second
+00:03:36.720 --> 00:03:40.199
+the more memory Emacs uses. So basically,
 
-08:27.440 --> 08:33.680
-and less than 0.1 second is usually just not noticeable. So even though there is garbage
+00:03:40.200 --> 00:03:44.439
+the more buffers you open, the more packages you load,
 
-08:33.680 --> 08:43.200
-collection it will not interrupt the work in Emacs. However there is a fraction of users who
+00:03:44.440 --> 00:03:48.319
+the more complex commands you run, the more memory is used,
 
-08:43.920 --> 08:49.680
-experience garbage collection it takes like 0.2, 0.3 or even half a second which will be quite
+00:03:48.320 --> 00:03:52.279
+and basically, the longer Emacs takes
 
-08:49.680 --> 08:58.800
-noticeable. For the purposes of this study I will consider that anything that is less than 0.1
+00:03:52.280 --> 00:03:57.919
+to perform a single garbage collection.
 
-08:58.800 --> 09:06.000
-second which is insignificant so like you will not notice it and it's like obviously all the Emacs
+00:03:57.920 --> 00:04:02.279
+Of course, Emacs being Emacs
 
-09:06.000 --> 09:13.600
-usage will be just normal. But if it's more than 0.1 or 0.2 seconds then it will be very noticeable
+00:04:02.280 --> 00:04:06.039
+this garbage collection can be tweaked.
 
-09:13.600 --> 09:20.800
-and you will see that Emacs hang for a little while or not so little while. In terms of numbers
+00:04:06.040 --> 00:04:08.279
+In particular users can tweak
 
-09:21.360 --> 09:28.000
-it's better to plot the statistics not as a distribution but as a cumulative distribution.
+00:04:08.280 --> 00:04:10.639
+how frequently Emacs does garbage collection
 
-09:29.040 --> 09:34.080
-So like at every point of this graph you'll see like for example here 0.4 seconds
+00:04:10.640 --> 00:04:13.879
+using two basic variables: `gc-cons-threshold`
 
-09:34.480 --> 09:49.040
-you have this percent of like almost 90% of users have no more than 0.4 gc duration. So like
+00:04:13.880 --> 00:04:15.519
+and `gc-cons-percentage`.
 
-09:49.040 --> 09:55.760
-we can look here if we take one gc critical gc duration which is 0.1 second
+00:04:15.520 --> 00:04:21.599
+`gc-cons-threshold` is the raw number of kilobytes
 
-09:55.840 --> 10:02.400
-0.1 second and look at how many users have it so we have 56% which is like
+00:04:21.600 --> 00:04:22.479
+Emacs needs to allocate
 
-10:03.600 --> 10:12.880
-44% users have less than 0.1 second gc duration and the rest 56% have more than 0.1 second.
+00:04:22.480 --> 00:04:25.959
+before triggering another garbage collection,
 
-10:13.600 --> 10:20.720
-So you can see like more than half of users actually have noticeable gc delay so the
+00:04:25.960 --> 00:04:27.799
+and the `gc-cons-percentage` is similar,
 
-10:20.720 --> 10:27.040
-Emacs freezes for some noticeable time and a quarter of users actually have very noticeable
+00:04:27.800 --> 00:04:30.399
+but it's defined in terms of fraction
 
-10:27.040 --> 10:36.640
-so like Emacs freezes such that you see an actual delay that Emacs actually has
+00:04:30.400 --> 00:04:34.759
+of already-allocated memory.
 
-10:37.760 --> 10:47.600
-which is quite significant and important point. But apart from the duration of each individual gc
+00:04:34.760 --> 00:04:38.239
+If you follow various Emacs forums,
 
-10:47.600 --> 10:52.640
-it is important to see how frequent it is because even if you do notice a delay
+00:04:38.240 --> 00:04:41.959
+you may be familiar with people complaining about
 
-10:53.440 --> 10:59.120
-even a few seconds delay it doesn't matter if it happens once during the whole Emacs session.
+00:04:41.960 --> 00:04:46.479
+garbage collection. There are many many suggestions
 
-11:01.360 --> 11:10.720
-So if you look into frequency distribution again here I plot time between
+00:04:46.480 --> 00:04:48.039
+about what to do with it.
 
-11:11.680 --> 11:17.760
-subsequent garbage collections versus how frequent it is and we have very clear trend that
+00:04:48.040 --> 00:04:54.079
+Most frequently, you see `gc-cons-threshold`
 
-11:18.560 --> 11:24.560
-most of the garbage collections are quite frequent like we talk about every few seconds a few tens
+00:04:54.080 --> 00:04:56.879
+recommended to be increased,
 
-11:24.560 --> 11:32.560
-of seconds. There's a few outliers which are at very round numbers like 60 seconds, 120 seconds,
+00:04:56.880 --> 00:05:01.439
+and a number of pre-packaged Emacs distributions
 
-11:32.560 --> 11:40.640
-300 seconds. These are usually timers so like you have something running on timer and then it
+00:05:01.440 --> 00:05:04.319
+like Doom Emacs do increase it.
 
-11:41.440 --> 11:48.000
-is complex command and it triggers garbage collection but it's not the majority.
+00:05:04.320 --> 00:05:07.279
+I have seen suggestions which are actually horrible
 
-11:49.280 --> 11:54.000
-Again to run the numbers it's better to look into cumulative distribution and see that
+00:05:07.280 --> 00:05:10.479
+to disable garbage collection temporarily
 
-11:54.000 --> 11:58.160
-50% of garbage collections are basically less than 10 seconds apart.
+00:05:10.480 --> 00:05:14.359
+or for a long time.
 
-12:00.000 --> 12:07.920
-And we can combine it with previous data and we look into whatever garbage collection takes
+00:05:14.360 --> 00:05:17.519
+Which is nice... You can see it quite frequently,
 
-12:07.920 --> 12:12.960
-less than 10 seconds from each other and also takes more than say 0.1 seconds.
+00:05:17.520 --> 00:05:19.399
+which indicates there might be some problem.
 
-12:13.680 --> 12:20.800
-So and then we see that one quarter of all garbage collections are just noticeable and also frequent
+00:05:19.400 --> 00:05:23.959
+However, every time one user poses about this problem,
 
-12:21.760 --> 12:27.840
-and 9% are not like more than 0.2% very noticeable and also frequent. So basically
+00:05:23.960 --> 00:05:26.879
+it's just one data point and it doesn't mean
 
-12:27.840 --> 12:34.480
-it constitutes Emacs freezing. So 9% of all the garbage collection Emacs freezing. Of course
+00:05:26.880 --> 00:05:28.879
+that everyone actually suffers from it.
 
-12:35.360 --> 12:42.960
-if you remember there is a bias but 9% is quite significant number. So garbage collection can
+00:05:28.880 --> 00:05:33.719
+It doesn't mean that everyone should do it.
 
-12:42.960 --> 12:47.280
-really slow down things not for everyone but for significant fraction of users.
+00:05:33.720 --> 00:05:35.919
+So in order to understand if this garbage collection
 
-12:49.440 --> 12:57.440
-Another thing I'd like to look into is what I call agglomerated GCs. What I mean by agglomerated
+00:05:35.920 --> 00:05:39.959
+is really a problem which is a common problem
 
-12:57.440 --> 13:02.720
-is when you have one garbage collection and then another garbage immediately after it. So
+00:05:39.960 --> 00:05:44.919
+we do need some kind of statistics
 
-13:03.680 --> 13:09.840
-in terms of numbers I took every subsequent garbage collection which is either immediately
+00:05:44.920 --> 00:05:46.919
+and only using the actual statistics
 
-13:09.840 --> 13:16.000
-after or no more than one second after each. So from point of view of users is like
+00:05:46.920 --> 00:05:52.759
+we can understand if it should be recommended for everyone
 
-13:16.960 --> 13:22.880
-multiple garbage collection they add up together into one giant garbage collection.
+00:05:52.760 --> 00:05:54.999
+to tweak the defaults or like whether
 
-13:23.440 --> 13:29.440
-And if you look into numbers of how many agglomerated garbage collections there are
+00:05:55.000 --> 00:05:57.159
+it should be recommended for certain users
 
-13:29.440 --> 13:35.360
-you can see even numbers over 100. So 100 garbage collection going one after another.
+00:05:57.160 --> 00:05:59.479
+or maybe it should be asked Emacs devs
 
-13:36.720 --> 13:42.560
-Even if you think about each garbage collection taking 0.1 second we look into 100 of them
+00:05:59.480 --> 00:06:01.559
+to do something about the defaults.
 
-13:43.280 --> 13:50.480
-it's total 10 seconds. It's like Emacs hanging forever or like a significant number is also 10.
+00:06:01.560 --> 00:06:07.959
+And what I did some time ago is exactly this.
 
-13:50.480 --> 13:58.160
-So again this would be very annoying to meet such thing. How frequently does it happen? Again we
+00:06:07.960 --> 00:06:09.959
+I tried to collect the user statistics.
 
-13:58.160 --> 14:04.400
-can plot cumulative distribution and we see that 20 percent like 19 percent of all the garbage
+00:06:09.960 --> 00:06:14.519
+So I wrote a small package on Elp
 
-14:04.400 --> 14:13.680
-collection are at least two together and 8 percent like more than 10. So like you think about oh
+00:06:14.520 --> 00:06:18.159
+and some users installed this package
 
-14:13.680 --> 14:17.840
-each garbage collection is not taking much time but when you have 10 of them yeah that becomes a
+00:06:18.160 --> 00:06:22.119
+and then reported back these statistics
 
-14:17.840 --> 14:32.560
-problem. Another thing is to answer a question that some people complain about is that
+00:06:22.120 --> 00:06:24.279
+of the garbage collection for their particular use.
 
-14:33.680 --> 14:42.320
-longer you use Emacs the slower Emacs become. Of course it may be caused by garbage collection and
+00:06:24.280 --> 00:06:30.799
+By now we have obtained 129 user submissions
 
-14:42.720 --> 14:50.000
-I wanted to look into how garbage collection time and other statistics, other parameters
+00:06:30.800 --> 00:06:34.039
+with over 1 million GC records in there.
 
-14:50.880 --> 14:58.880
-are evolving over time. And what I can see here is a cumulative distribution of GC duration
+00:06:34.040 --> 00:06:38.119
+So like some of these submissions
 
-14:59.680 --> 15:04.720
-for like first 10 minutes of Emacs uptime first 100 minutes first 1000 minutes.
+00:06:38.120 --> 00:06:43.159
+used default GC settings without any customizations.
 
-15:05.520 --> 15:13.840
-And if you look closer then you see that each individual garbage collection on average
+00:06:43.160 --> 00:06:46.039
+Some used increased GC cost threshold
 
-15:15.440 --> 15:24.000
-takes longer as you use Emacs longer. However this longer is not much it's like maybe 10 percent
+00:06:46.040 --> 00:06:47.799
+and GC cost percentage.
 
-15:24.000 --> 15:33.040
-like basically garbage collection gets like slow Emacs down more as you use Emacs more
+00:06:47.800 --> 00:06:53.319
+So using this data we can try to draw
 
-15:33.680 --> 15:40.320
-but not much. So basically if you do you see Emacs being slower and slower over time
+00:06:53.320 --> 00:06:56.879
+some reliable conclusions on what should be done
 
-15:40.960 --> 15:46.960
-it's probably not really garbage collection because it doesn't change too much. And if you
+00:06:56.880 --> 00:06:59.919
+and whether should anything be done about garbage collection
 
-15:46.960 --> 15:52.720
-look into time between individual garbage collections and you see that the time actually
+00:06:59.920 --> 00:07:02.639
+on Emacs dev level or at least on user level.
 
-15:52.720 --> 15:58.880
-increases as you use Emacs longer which makes sense because initially like first few minutes
+00:07:02.640 --> 00:07:05.639
+Of course we need to keep in mind
 
-15:58.880 --> 16:04.720
-you have all kind of packages loading like all the port loading and then later everything is
+00:07:05.640 --> 00:07:07.279
+that there's some kind of bias
 
-16:04.720 --> 16:12.560
-loaded and things become more stable. So the conclusion on this part is that
+00:07:07.280 --> 00:07:08.999
+because it's more likely
 
-16:13.520 --> 16:18.480
-if Emacs becomes slower in a long session it's probably not caused by garbage collection.
+00:07:09.000 --> 00:07:11.719
+that users already have problems with GC
 
-16:20.320 --> 16:27.760
-And one word of warning of course is that it's all nice and all when I present the statistics
+00:07:11.720 --> 00:07:13.239
+or they think they have problems with GC
 
-16:27.760 --> 16:32.800
-but it's only an average and if you are an actual user like here is one example
+00:07:13.240 --> 00:07:15.919
+will report and submit the data.
 
-16:34.080 --> 16:39.920
-which shows a total garbage collection time like accumulated together over Emacs uptime
+00:07:15.920 --> 00:07:19.999
+But anyway having s statistics is much more useful
 
-16:40.880 --> 16:45.360
-and you see different lines which correspond to different sessions of one user
+00:07:20.000 --> 00:07:22.079
+than just having anecdotal evidences
 
-16:46.800 --> 16:51.360
-and you see they are wildly different like one time there is almost no garbage collection
+00:07:22.080 --> 00:07:25.519
+from one or other reddit posts.
 
-16:52.240 --> 16:57.840
-another time you see garbage collection because probably Emacs is used more early or like
+00:07:25.520 --> 00:07:28.759
+And just one thing I will do
 
-16:57.840 --> 17:04.560
-different pattern of usage and even during a single Emacs session you see a different slope
+00:07:28.760 --> 00:07:30.879
+during the rest of my presentation
 
-17:04.560 --> 17:10.560
-of this curve which means that sometimes garbage collection is infrequent and sometimes it's much
+00:07:30.880 --> 00:07:32.839
+is that for all the statistics
 
-17:10.560 --> 17:16.000
-more frequent so it's probably much more noticeable one time and less noticeable other time.
+00:07:32.840 --> 00:07:35.679
+I will normalize user data
 
-17:16.000 --> 17:23.360
-So if you think about these statistics of course they only represent an average usage
+00:07:35.680 --> 00:07:37.879
+so that every user contributes equally.
 
-17:23.360 --> 17:26.240
+00:07:37.880 --> 00:07:40.279
+For example if one user submits like
+
+00:07:40.280 --> 00:07:43.119
+100 hours Emacs uptime statistics
+
+00:07:43.120 --> 00:07:46.279
+and other users submit one hour Emacs uptime
+
+00:07:46.280 --> 00:07:52.879
+then I will anyway make it so that they contribute equally.
+
+00:07:52.880 --> 00:07:56.359
+Let's start from one of the most obvious things
+
+00:07:56.360 --> 00:07:57.679
+we can look into is
+
+00:07:57.680 --> 00:08:00.599
+which is the time it takes for garbage collection
+
+00:08:00.600 --> 00:08:05.879
+to single garbage collection process.
+
+00:08:05.880 --> 00:08:11.839
+Here you see frequency distribution of GC duration
+
+00:08:11.840 --> 00:08:14.999
+for all the 129 users we got
+
+00:08:15.000 --> 00:08:22.279
+and you can see that most of the garbage collections
+
+00:08:22.280 --> 00:08:26.999
+are done quite quickly in less than 0.1 second
+
+00:08:27.000 --> 00:08:32.199
+and less than 0.1 second is usually just not noticeable.
+
+00:08:32.200 --> 00:08:34.519
+So even though there is garbage collection
+
+00:08:34.520 --> 00:08:39.639
+it will not interrupt the work in Emacs.
+
+00:08:39.640 --> 00:08:43.279
+However there is a fraction of users
+
+00:08:43.280 --> 00:08:45.279
+who experience garbage collection
+
+00:08:45.280 --> 00:08:48.399
+it takes like 0.2, 0.3 or even half a second
+
+00:08:48.400 --> 00:08:50.399
+which will be quite noticeable.
+
+00:08:50.400 --> 00:08:55.279
+For the purposes of this study
+
+00:08:55.280 --> 00:08:59.399
+I will consider that anything that is less than 0.1 second
+
+00:08:59.400 --> 00:09:02.639
+which is insignificant so like you will not notice it
+
+00:09:02.640 --> 00:09:04.159
+and it's like obviously
+
+00:09:04.160 --> 00:09:07.479
+all the Emacs usage will be just normal.
+
+00:09:07.480 --> 00:09:11.639
+But if it's more than 0.1 or 0.2 seconds
+
+00:09:11.640 --> 00:09:13.799
+then it will be very noticeable
+
+00:09:13.800 --> 00:09:16.079
+and you will see that Emacs hang for a little while
+
+00:09:16.080 --> 00:09:21.319
+or not so little while. In terms of numbers
+
+00:09:21.320 --> 00:09:26.239
+it's better to plot the statistics not as a distribution
+
+00:09:26.240 --> 00:09:28.199
+but as a cumulative distribution.
+
+00:09:28.200 --> 00:09:31.559
+So like at every point of this graph
+
+00:09:31.560 --> 00:09:37.159
+you'll see like for example here 0.4 seconds
+
+00:09:37.160 --> 00:09:42.279
+you have this percent of like almost 90% of users
+
+00:09:42.280 --> 00:09:49.279
+have no more than 0.4 gc duration.
+
+00:09:49.280 --> 00:09:53.239
+So like we can look here if we take one
+
+00:09:53.240 --> 00:09:56.879
+gc critical gc duration which is 0.1 second
+
+00:09:56.880 --> 00:10:00.279
+0.1 second and look at how many users have
+
+00:10:00.280 --> 00:10:02.439
+it so we have 56% which is like
+
+00:10:02.440 --> 00:10:09.439
+44% users have less than 0.1 second gc duration
+
+00:10:09.440 --> 00:10:12.839
+and the rest 56% have more than 0.1 second.
+
+00:10:12.840 --> 00:10:16.279
+So you can see like more than half of users
+
+00:10:16.280 --> 00:10:20.559
+actually have noticeable gc delay
+
+00:10:20.560 --> 00:10:22.999
+so the Emacs freezes for some noticeable time
+
+00:10:23.000 --> 00:10:27.479
+and a quarter of users actually have very noticeable
+
+00:10:27.480 --> 00:10:31.799
+so like Emacs freezes such that you see an actual delay
+
+00:10:31.800 --> 00:10:36.879
+that Emacs actually has
+
+00:10:36.880 --> 00:10:44.079
+which is quite significant and important point.
+
+00:10:44.080 --> 00:10:47.719
+But apart from the duration of each individual gc
+
+00:10:47.720 --> 00:10:49.839
+it is important to see how frequent it is
+
+00:10:49.840 --> 00:10:52.879
+because even if you do notice a delay
+
+00:10:52.880 --> 00:10:54.959
+even a few seconds delay
+
+00:10:54.960 --> 00:10:56.999
+it doesn't matter if it happens once
+
+00:10:57.000 --> 00:10:59.199
+during the whole Emacs session.
+
+00:10:59.200 --> 00:11:05.039
+So if you look into frequency distribution again here
+
+00:11:05.040 --> 00:11:13.639
+I plot time between subsequent garbage collections
+
+00:11:13.640 --> 00:11:17.959
+versus how frequent it is and we have very clear trend
+
+00:11:17.960 --> 00:11:21.799
+that most of the garbage collections are quite frequent
+
+00:11:21.800 --> 00:11:25.159
+like we talk about every few seconds a few tens of seconds.
+
+00:11:25.160 --> 00:11:30.039
+There's a few outliers which are at very round numbers
+
+00:11:30.040 --> 00:11:35.839
+like 60 seconds, 120 seconds, 300 seconds.
+
+00:11:35.840 --> 00:11:37.879
+These are usually timers so like
+
+00:11:37.880 --> 00:11:40.319
+you have something running on timer
+
+00:11:40.320 --> 00:11:43.599
+and then it is complex command
+
+00:11:43.600 --> 00:11:45.079
+and it triggers garbage collection
+
+00:11:45.080 --> 00:11:48.079
+but it's not the majority.
+
+00:11:48.080 --> 00:11:51.279
+Again to run the numbers
+
+00:11:51.280 --> 00:11:53.679
+it's better to look into cumulative distribution
+
+00:11:53.680 --> 00:11:56.039
+and see that 50% of garbage collections
+
+00:11:56.040 --> 00:11:58.279
+are basically less than 10 seconds apart.
+
+00:11:58.280 --> 00:12:02.359
+And we can combine it with previous data
+
+00:12:02.360 --> 00:12:07.479
+and we look into whatever garbage collection
+
+00:12:07.480 --> 00:12:09.959
+takes less than 10 seconds from each other
+
+00:12:09.960 --> 00:12:13.119
+and also takes more than say 0.1 seconds.
+
+00:12:13.120 --> 00:12:15.319
+So and then we see that
+
+00:12:15.320 --> 00:12:17.639
+one quarter of all garbage collections
+
+00:12:17.640 --> 00:12:21.039
+are just noticeable and also frequent
+
+00:12:21.040 --> 00:12:23.679
+and 9% are not like
+
+00:12:23.680 --> 00:12:27.199
+more than 0.2% very noticeable and also frequent.
+
+00:12:27.200 --> 00:12:30.079
+So basically it constitutes Emacs freezing.
+
+00:12:30.080 --> 00:12:33.559
+So 9% of all the garbage collection Emacs freezing.
+
+00:12:33.560 --> 00:12:37.319
+Of course if you remember there is a bias
+
+00:12:37.320 --> 00:12:40.519
+but 9% is quite significant number.
+
+00:12:40.520 --> 00:12:44.319
+So garbage collection can really slow down things
+
+00:12:44.320 --> 00:12:48.239
+not for everyone but for significant fraction of users.
+
+00:12:48.240 --> 00:12:52.159
+Another thing I'd like to look into
+
+00:12:52.160 --> 00:12:55.399
+is what I call agglomerated GCs.
+
+00:12:55.400 --> 00:12:57.959
+What I mean by agglomerated is
+
+00:12:57.960 --> 00:13:00.359
+when you have one garbage collection
+
+00:13:00.360 --> 00:13:02.999
+and then another garbage immediately after it.
+
+00:13:03.000 --> 00:13:05.559
+So in terms of numbers I took
+
+00:13:05.560 --> 00:13:08.719
+every subsequent garbage collection
+
+00:13:08.720 --> 00:13:10.399
+which is either immediately after
+
+00:13:10.400 --> 00:13:13.039
+or no more than one second after each.
+
+00:13:13.040 --> 00:13:16.159
+So from point of view of users is like
+
+00:13:16.160 --> 00:13:19.999
+multiple garbage collection they add up together
+
+00:13:20.000 --> 00:13:22.999
+into one giant garbage collection.
+
+00:13:23.000 --> 00:13:25.839
+And if you look into numbers
+
+00:13:25.840 --> 00:13:29.559
+of how many agglomerated garbage collections there are
+
+00:13:29.560 --> 00:13:32.119
+you can see even numbers over 100.
+
+00:13:32.120 --> 00:13:35.479
+So 100 garbage collection going one after another.
+
+00:13:35.480 --> 00:13:39.159
+Even if you think about each garbage collection
+
+00:13:39.160 --> 00:13:42.719
+taking 0.1 second we look into 100 of them
+
+00:13:42.720 --> 00:13:44.639
+it's total 10 seconds.
+
+00:13:44.640 --> 00:13:46.839
+It's like Emacs hanging forever
+
+00:13:46.840 --> 00:13:53.519
+or like a significant number is also 10.
+
+00:13:53.520 --> 00:13:55.999
+So again this would be very annoying to meet such thing.
+
+00:13:56.000 --> 00:13:57.879
+How frequently does it happen?
+
+00:13:57.880 --> 00:14:00.279
+Again we can plot cumulative distribution
+
+00:14:00.280 --> 00:14:03.879
+and we see that 20 percent like 19 percent
+
+00:14:03.880 --> 00:14:07.199
+of all the garbage collection are at least two together
+
+00:14:07.200 --> 00:14:13.679
+and 8 percent like more than 10. So like you think about oh
+
+00:14:13.680 --> 00:14:15.639
+each garbage collection is not taking much time
+
+00:14:15.640 --> 00:14:24.479
+but when you have 10 of them yeah that becomes a problem.
+
+00:14:24.480 --> 00:14:29.919
+Another thing is to answer a question
+
+00:14:29.920 --> 00:14:32.959
+that some people complain about is that
+
+00:14:32.960 --> 00:14:35.799
+longer you use Emacs the slower Emacs become.
+
+00:14:35.800 --> 00:14:43.039
+Of course it may be caused by garbage collection
+
+00:14:43.040 --> 00:14:48.519
+and I wanted to look into how garbage collection time
+
+00:14:48.520 --> 00:14:49.679
+and other statistics,
+
+00:14:49.680 --> 00:14:53.199
+other parameters are evolving over time.
+
+00:14:53.200 --> 00:14:58.559
+And what I can see here is a cumulative distribution
+
+00:14:58.560 --> 00:15:03.719
+of GC duration for like first 10 minutes of Emacs uptime
+
+00:15:03.720 --> 00:15:06.479
+first 100 minutes first 1000 minutes.
+
+00:15:06.480 --> 00:15:10.199
+And if you look closer then you see
+
+00:15:10.200 --> 00:15:14.519
+that each individual garbage collection on average
+
+00:15:14.520 --> 00:15:18.959
+takes longer as you use Emacs longer.
+
+00:15:18.960 --> 00:15:24.039
+However this longer is not much it's like maybe 10 percent
+
+00:15:24.040 --> 00:15:29.479
+like basically garbage collection gets like
+
+00:15:29.480 --> 00:15:34.719
+slow Emacs down more as you use Emacs more but not much.
+
+00:15:34.720 --> 00:15:38.359
+So basically if you do you see Emacs
+
+00:15:38.360 --> 00:15:40.639
+being slower and slower over time
+
+00:15:40.640 --> 00:15:43.159
+it's probably not really garbage collection
+
+00:15:43.160 --> 00:15:45.839
+because it doesn't change too much.
+
+00:15:45.840 --> 00:15:48.119
+And if you look into time
+
+00:15:48.120 --> 00:15:50.839
+between individual garbage collections
+
+00:15:50.840 --> 00:15:53.719
+and you see that the time actually increases
+
+00:15:53.720 --> 00:15:56.719
+as you use Emacs longer which makes sense
+
+00:15:56.720 --> 00:15:58.839
+because initially like first few minutes
+
+00:15:58.840 --> 00:16:01.479
+you have all kind of packages loading
+
+00:16:01.480 --> 00:16:04.239
+like all the port loading and then later
+
+00:16:04.240 --> 00:16:07.239
+everything is loaded and things become more stable.
+
+00:16:07.240 --> 00:16:12.879
+So the conclusion on this part is that
+
+00:16:12.880 --> 00:16:16.399
+if Emacs becomes slower in a long session
+
+00:16:16.400 --> 00:16:18.479
+it's probably not caused by garbage collection.
+
+00:16:18.480 --> 00:16:23.679
+And one word of warning of course is that
+
+00:16:23.680 --> 00:16:27.919
+it's all nice and all when I present the statistics
+
+00:16:27.920 --> 00:16:29.279
+but it's only an average
+
+00:16:29.280 --> 00:16:34.079
+and if you are an actual user like here is one example
+
+00:16:34.080 --> 00:16:37.159
+which shows a total garbage collection time
+
+00:16:37.160 --> 00:16:40.119
+like accumulated together over Emacs uptime
+
+00:16:40.120 --> 00:16:43.199
+and you see different lines
+
+00:16:43.200 --> 00:16:45.559
+which correspond to different sessions of one user
+
+00:16:45.560 --> 00:16:48.679
+and you see they are wildly different
+
+00:16:48.680 --> 00:16:51.439
+like one time there is almost no garbage collection
+
+00:16:51.440 --> 00:16:54.679
+another time you see garbage collection
+
+00:16:54.680 --> 00:16:56.999
+because probably Emacs is used more early
+
+00:16:57.000 --> 00:16:59.599
+or like different pattern of usage
+
+00:16:59.600 --> 00:17:03.159
+and even during a single Emacs session
+
+00:17:03.160 --> 00:17:04.599
+you see a different slope
+
+00:17:04.600 --> 00:17:06.439
+of this curve which means that
+
+00:17:06.440 --> 00:17:09.279
+sometimes garbage collection is infrequent
+
+00:17:09.280 --> 00:17:11.479
+and sometimes it's much more frequent
+
+00:17:11.480 --> 00:17:14.479
+so it's probably much more noticeable one time
+
+00:17:14.480 --> 00:17:15.639
+and less noticeable other time.
+
+00:17:15.640 --> 00:17:19.719
+So if you think about these statistics of course
+
+00:17:19.720 --> 00:17:23.359
+they only represent an average usage
+
+00:17:23.360 --> 00:17:26.359
 but sometimes it can get worse sometimes it can get better.
 
-17:30.320 --> 17:35.600
-The last parameter I'd like to talk about is garbage collection during Emacs init.
+00:17:26.360 --> 00:17:33.759
+The last parameter I'd like to talk about is
 
-17:36.960 --> 17:42.320
-Basically if you think about what happens during Emacs init like when Emacs just starting up
+00:17:33.760 --> 00:17:35.799
+garbage collection during Emacs init.
 
-17:42.320 --> 17:46.720
-then whatever garbage collection there it's one or it's several times
+00:17:35.800 --> 00:17:40.439
+Basically if you think about what happens during Emacs init
 
-17:46.720 --> 17:50.640
+00:17:40.440 --> 00:17:41.919
+like when Emacs just starting up
+
+00:17:41.920 --> 00:17:44.479
+then whatever garbage collection
+
+00:17:44.480 --> 00:17:46.759
+there it's one or it's several times
+
+00:17:46.760 --> 00:17:51.239
 it all contributes to Emacs taking longer to start.
 
-17:53.200 --> 18:00.640
-And again we can look into the statistic and see what is the total GC duration after Emacs init
+00:17:51.240 --> 00:17:56.559
+And again we can look into the statistic
+
+00:17:56.560 --> 00:18:01.159
+and see what is the total GC duration after Emacs init
+
+00:18:01.160 --> 00:18:06.159
+and we see that 50% of all the submissions
+
+00:18:06.160 --> 00:18:10.279
+garbage collection adds up more than one second
+
+00:18:10.280 --> 00:18:14.919
+to Emacs init time and for 20% of users
+
+00:18:14.920 --> 00:18:17.079
+it's extra three seconds Emacs start time
+
+00:18:17.080 --> 00:18:18.479
+which is very significant
+
+00:18:18.480 --> 00:18:21.479
+especially for people who are used to Vim
+
+00:18:21.480 --> 00:18:23.919
+which can start in like a fraction of a second
+
+00:18:23.920 --> 00:18:26.239
+and here it just does garbage collection
+
+00:18:26.240 --> 00:18:27.439
+because garbage collection is not
+
+00:18:27.440 --> 00:18:29.239
+everything Emacs does during startup
+
+00:18:29.240 --> 00:18:31.999
+adds up more to the load.
+
+00:18:32.000 --> 00:18:36.119
+Okay that's all nice and all
+
+00:18:36.120 --> 00:18:38.679
+but what can we do about these statistics
+
+00:18:38.680 --> 00:18:40.159
+can we draw any conclusions
+
+00:18:40.160 --> 00:18:43.239
+and the answer is of course
+
+00:18:43.240 --> 00:18:46.079
+like the most important conclusion here is that
+
+00:18:46.080 --> 00:18:49.439
+yes garbage collection can slow down Emacs
+
+00:18:49.440 --> 00:18:52.679
+at least for some people and what to do about it
+
+00:18:52.680 --> 00:18:55.319
+there are two variables which you can tweak
+
+00:18:55.320 --> 00:18:58.719
+it's because gcconce threshold gcconce percentage
+
+00:18:58.720 --> 00:19:03.159
+and having the statistics I can at least look a little bit
+
+00:19:03.160 --> 00:19:08.879
+into what is the effect of increasing these variables
+
+00:19:08.880 --> 00:19:12.439
+like most people just increase gcconce threshold
+
+00:19:12.440 --> 00:19:16.959
+and like all the submissions people did increase
+
+00:19:16.960 --> 00:19:19.919
+and doesn't make much sense to decrease it
 
-18:01.840 --> 18:10.240
-and we see that 50% of all the submissions garbage collection adds up more than one second
+00:19:19.920 --> 00:19:21.079
+like to make things worse
 
-18:10.240 --> 18:17.760
-to Emacs init time and for 20% of users it's extra three seconds Emacs start time which is
+00:19:21.080 --> 00:19:27.639
+of course for these statistics
 
-18:17.760 --> 18:22.640
-very significant especially for people who are used to Vim which can start in like a fraction
+00:19:27.640 --> 00:19:31.559
+the exact values of this increased thresholds
 
-18:22.640 --> 18:27.200
-of a second and here it just does garbage collection because garbage collection is
+00:19:31.560 --> 00:19:33.839
+are not always the same
 
-18:27.200 --> 18:31.760
-not everything Emacs does during startup adds up more to the load.
+00:19:33.840 --> 00:19:36.479
+but at least we can look into some trends
 
-18:33.680 --> 18:39.280
-Okay that's all nice and all but what can we do about these statistics can we draw any
+00:19:36.480 --> 00:19:44.759
+so first and obvious thing we can observe
 
-18:39.280 --> 18:46.000
-conclusions and the answer is of course like the most important conclusion here is that
+00:19:44.760 --> 00:19:46.759
+is when we compare
 
-18:46.720 --> 18:52.320
-yes garbage collection can slow down Emacs at least for some people and what to do about it
+00:19:46.760 --> 00:19:50.399
+the standard gc settings standard thresholds
 
-18:53.360 --> 18:58.720
-there are two variables which you can tweak it's because gcconce threshold gcconce percentage
+00:19:50.400 --> 00:19:53.999
+and increased thresholds for time between
 
-18:58.720 --> 19:06.400
-and having the statistics I can at least look a little bit into what is the effect of
+00:19:54.000 --> 00:19:57.479
+subsequent gcs and as one may expect
 
-19:06.400 --> 19:12.400
-increasing these variables like most people just increase gcconce threshold
+00:19:57.480 --> 00:19:59.559
+if you increase the threshold
 
-19:13.760 --> 19:17.040
-and like all the submissions people did increase and
+00:19:59.560 --> 00:20:02.679
+Emacs will do garbage collection less frequently
 
-19:17.680 --> 19:20.880
-doesn't make much sense to decrease it like to make things worse
+00:20:02.680 --> 00:20:05.279
+so the spacing between garbage collection increases
 
-19:24.560 --> 19:31.280
-of course for these statistics the exact values of this increased thresholds
+00:20:05.280 --> 00:20:07.599
+okay the only thing is that
 
-19:31.680 --> 19:36.320
-are not always the same but at least we can look into some trends
+00:20:07.600 --> 00:20:10.719
+if garbage collection is less frequent
 
-19:38.640 --> 19:48.480
-so first and obvious thing we can observe is when we compare the standard gc settings
+00:20:10.720 --> 00:20:14.079
+then each individual garbage collection becomes longer
 
-19:49.120 --> 19:57.680
-standard thresholds and increased thresholds for time between subsequent gcs and as one may expect
+00:20:14.080 --> 00:20:18.159
+so if you think about increasing
 
-19:57.680 --> 20:03.440
-if you increase the threshold Emacs will do garbage collection less frequently so the spacing
+00:20:18.160 --> 00:20:22.239
+garbage collection thresholds be prepared
 
-20:03.440 --> 20:10.080
-between garbage collection increases okay the only thing is that if garbage collection is
+00:20:22.240 --> 00:20:26.519
+that in each individual time Emacs freezes will take longer
 
-20:10.080 --> 20:16.800
-less frequent then each individual garbage collection becomes longer so if you think about
+00:20:26.520 --> 00:20:31.599
+this is one caveat when we talk about
 
-20:16.800 --> 20:24.240
-increasing garbage collection thresholds be prepared that in each individual time Emacs
+00:20:31.600 --> 00:20:34.079
+this agglomerated gcs which are one after other
 
-20:24.240 --> 20:33.040
-freezes will take longer this is one caveat when we talk about this agglomerated gcs which
+00:20:34.080 --> 00:20:36.759
+like if you increase the threshold sufficiently
 
-20:33.040 --> 20:40.160
-are one after other like if you increase the threshold sufficiently then whatever happened
+00:20:36.760 --> 00:20:42.319
+then whatever happened that garbage collections
 
-20:40.160 --> 20:46.880
-that garbage collections were like done one after other we can now make it so that they are actually
+00:20:42.320 --> 00:20:44.399
+were like done one after other
 
-20:46.880 --> 20:53.840
-separated so like you don't see one giant freeze caused by like 10 gcs in a row instead you can
+00:20:44.400 --> 00:20:47.599
+we can now make it so that they are actually separated
 
-20:53.840 --> 21:00.880
-make it so that they are separated and in statistics it's very clear that the number of
+00:20:47.600 --> 00:20:51.559
+so like you don't see one giant freeze caused by
 
-21:00.880 --> 21:06.560
-agglomerated garbage collections decreases dramatically when you increase the thresholds
+00:20:51.560 --> 00:20:52.919
+like 10 gcs in a row
 
-21:07.920 --> 21:11.600
+00:20:52.920 --> 00:20:55.759
+instead you can make it so that they are separated
+
+00:20:55.760 --> 00:20:59.079
+and in statistics it's very clear
+
+00:20:59.080 --> 00:21:02.959
+that the number of agglomerated garbage collections
+
+00:21:02.960 --> 00:21:06.919
+decreases dramatically when you increase the thresholds
+
+00:21:06.920 --> 00:21:11.759
 it's particularly evident when we look into startup time
 
-21:13.520 --> 21:19.680
-if you look at gc duration during Emacs startup and if we look into what happens when you
+00:21:11.760 --> 00:21:17.279
+if you look at gc duration during Emacs startup
+
+00:21:17.280 --> 00:21:19.159
+and if we look into what happens
+
+00:21:19.160 --> 00:21:20.879
+when you increase the thresholds
+
+00:21:20.880 --> 00:21:23.799
+it's very clear that Emacs startup become faster
+
+00:21:23.800 --> 00:21:26.279
+when you increase gc thresholds
+
+00:21:26.280 --> 00:21:33.359
+so that's all for actual user statistics
+
+00:21:33.360 --> 00:21:35.439
+and now let's try to run into
+
+00:21:35.440 --> 00:21:38.079
+some like actual recommendations
+
+00:21:38.080 --> 00:21:42.639
+on what numbers to set and before we start
+
+00:21:42.640 --> 00:21:44.399
+let me explain a little bit about
+
+00:21:44.400 --> 00:21:46.479
+the difference between these two variables
+
+00:21:46.480 --> 00:21:48.879
+which is gc constant threshold and gc constant percentage
+
+00:21:48.880 --> 00:21:52.359
+so if you think about Emacs memory
+
+00:21:52.360 --> 00:21:55.239
+like there's a certain memory allocated by Emacs
+
+00:21:55.240 --> 00:21:58.479
+and then as you run commands and turn using Emacs
+
+00:21:58.480 --> 00:22:00.079
+there is more memory allocated
+
+00:22:00.080 --> 00:22:04.639
+and Emacs decides when to do garbage collection
+
+00:22:04.640 --> 00:22:06.079
+according these two variables
+
+00:22:06.080 --> 00:22:08.759
+and actually what it does it chooses the larger one
+
+00:22:08.760 --> 00:22:12.119
+so say you have you are late in Emacs session
+
+00:22:12.120 --> 00:22:14.039
+you have a lot of Emacs memory allocated
+
+00:22:14.040 --> 00:22:17.119
+then you have gc constant percentage
+
+00:22:17.120 --> 00:22:19.919
+which is percent of the already allocated memory
+
+00:22:19.920 --> 00:22:25.119
+and that percent is probably going to be the largest
+
+00:22:25.120 --> 00:22:28.319
+because you have more memory
+
+00:22:28.320 --> 00:22:32.559
+and memory means that percent of it is larger
+
+00:22:32.560 --> 00:22:36.359
+so like you have a larger number cost
+
+00:22:36.360 --> 00:22:37.719
+by gc constant percentage
+
+00:22:37.720 --> 00:22:43.079
+so in this scenario when Emacs session is already running
+
+00:22:43.080 --> 00:22:45.319
+for a long time and there is a lot of memory allocated
+
+00:22:45.320 --> 00:22:50.119
+you have gc constant percentage
+
+00:22:50.120 --> 00:22:52.279
+controlling the garbage collection
+
+00:22:52.280 --> 00:22:54.999
+while early in Emacs there is not much memory placed
+
+00:22:55.000 --> 00:22:58.719
+Emacs just starting up then gc constant threshold
+
+00:22:58.720 --> 00:23:01.639
+is controlling how frequently garbage collection happens
+
+00:23:01.640 --> 00:23:04.799
+because smaller allocated memory
 
-21:19.680 --> 21:25.680
-increase the thresholds it's very clear that Emacs startup become faster when you increase gc
+00:23:04.800 --> 00:23:06.839
+means its percentage will be a small number
 
-21:25.680 --> 21:37.120
-thresholds so that's all for actual user statistics and now let's try to run into some like actual
+00:23:06.840 --> 00:23:12.319
+so in terms of default values at least
 
-21:37.120 --> 21:44.480
-recommendations on what numbers to set and before we start let me explain a little bit about
+00:23:12.320 --> 00:23:14.239
+gc constant threshold is 800 kilobytes
 
-21:44.480 --> 21:48.720
-the difference between these two variables which is gc constant threshold and gc constant percentage
+00:23:14.240 --> 00:23:18.799
+and gc constant percentage is 10
 
-21:49.440 --> 21:55.120
-so if you think about Emacs memory like there's a certain memory allocated by Emacs
+00:23:18.800 --> 00:23:24.159
+so gc constant percentage becomes larger than that threshold
 
-21:56.000 --> 22:00.000
-and then as you run commands and turn using Emacs there is more memory allocated
+00:23:24.160 --> 00:23:28.919
+when you have more than eight megabytes of allocated memory
 
-22:01.360 --> 22:07.120
-and Emacs decides when to do garbage collection according these two variables and actually what
+00:23:28.920 --> 00:23:31.039
+by Emacs which is quite early
 
-22:07.120 --> 22:12.880
-it does it chooses the larger one so say you have you are late in Emacs session you have a lot of
+00:23:31.040 --> 00:23:34.279
+and it will probably hold just during the startup
 
-22:12.880 --> 22:18.960
-Emacs memory allocated then you have gc constant percentage which is percent of the already
+00:23:34.280 --> 00:23:36.799
+and once you start using your maximum
 
-22:18.960 --> 22:27.360
-allocated memory and that percent is probably going to be the largest because you have more memory and
+00:23:36.800 --> 00:23:38.919
+and once you load all the histories
 
-22:28.800 --> 22:34.480
-memory means that percent of it is larger so like you have a larger number
+00:23:38.920 --> 00:23:42.039
+all the kinds of buffers it's probably going to take
 
-22:35.040 --> 22:41.680
-cost by gc constant percentage so in this scenario when Emacs session is
+00:23:42.040 --> 00:23:43.959
+more than much more than eight megabytes
 
-22:42.240 --> 22:46.880
-already running for a long time and there is a lot of memory allocated you have
+00:23:43.960 --> 00:23:50.639
+so now we understand this
 
-22:49.600 --> 22:54.240
-gc constant percentage controlling the garbage collection while early in Emacs there is not much
+00:23:50.640 --> 00:23:53.279
+we can draw certain recommendations
 
-22:54.240 --> 23:00.240
-memory placed Emacs just starting up then gc constant threshold is controlling how frequently
+00:23:53.280 --> 00:23:57.279
+about tweaking the gc thresholds
 
-23:00.240 --> 23:06.160
-garbage collection happens because smaller allocated memory means its percentage will be a
+00:23:57.280 --> 00:24:01.159
+so first of all I need to emphasize
 
-23:06.160 --> 23:14.080
-small number so in terms of default values at least gc constant threshold is 800 kilobytes
+00:24:01.160 --> 00:24:03.639
+that any time you increase gc threshold
 
-23:14.800 --> 23:24.080
-and gc constant percentage is 10 so gc constant percentage becomes larger than that threshold
+00:24:03.640 --> 00:24:07.199
+an individual garbage collection time increases
 
-23:24.080 --> 23:30.480
-when you have more than eight megabytes of allocated memory by Emacs which is quite early
+00:24:07.200 --> 00:24:08.759
+so it's not free at all
 
-23:30.480 --> 23:37.040
-and it will probably hold just during the startup and once you start using your maximum
+00:24:08.760 --> 00:24:10.999
+if you don't have problems with garbage collection
 
-23:37.040 --> 23:42.080
-and once you load all the histories all the kinds of buffers it's probably going to take
+00:24:11.000 --> 00:24:13.519
+which is half of the users don't have much problem
 
-23:42.080 --> 23:52.320
-more than much more than eight megabytes so now we understand this we can draw certain
+00:24:13.520 --> 00:24:15.079
+you don't need to tweak anything
 
-23:52.320 --> 24:00.960
-recommendations about tweaking the gc thresholds so first of all I need to emphasize that
+00:24:15.080 --> 00:24:19.359
+only when gc is frequent and slow
 
-24:01.760 --> 24:07.840
-any time you increase gc threshold an individual garbage collection time increases so it's not
+00:24:19.360 --> 00:24:23.399
+when Emacs is really really present frequently
 
-24:07.840 --> 24:12.320
-free at all if you don't have problems with garbage collection which is half of the users
+00:24:23.400 --> 00:24:27.119
+you may consider increasing gc thresholds only
 
-24:12.320 --> 24:19.360
-don't have much problem you don't need to tweak anything only when gc is frequent and slow
+00:24:27.120 --> 00:24:31.479
+and in particular I recommend
 
-24:19.360 --> 24:27.040
-when Emacs is really really present frequently you may consider increasing gc thresholds only
+00:24:31.480 --> 00:24:33.279
+increasing gc constant percentage
 
-24:28.240 --> 24:35.040
-and in particular I recommend increasing gc constant percentage because that's what mostly
+00:24:33.280 --> 00:24:36.359
+because that's what mostly controls gc
 
-24:35.040 --> 24:43.600
-controls gc when Emacs is running for long session and the numbers are probably like
+00:24:36.360 --> 00:24:40.079
+when Emacs is running for long session
 
-24:43.600 --> 24:48.640
-yeah we can estimate the effect of these numbers like for example if you have a default value of
+00:24:40.080 --> 00:24:43.039
+and the numbers are probably like
 
-24:48.640 --> 24:54.720
-0.1 percent for gc constant percentage 0.1 which is 10 percent and then increase it twice
+00:24:43.040 --> 00:24:46.519
+yeah we can estimate the effect of these numbers
 
-24:55.760 --> 25:02.880
-obviously you get twice less frequent gcs but it will come at the cost of extra 10 percent gc time
+00:24:46.520 --> 00:24:49.679
+like for example if you have a default value of 0.1 percent
 
-25:02.880 --> 25:09.840
-and if you increase 10 times you can think about 10 less 10 x less frequent gcs but almost twice
+00:24:49.680 --> 00:24:52.759
+for gc constant percentage 0.1 which is 10 percent
 
-25:09.840 --> 25:16.880
-longer individual garbage collection time so probably you want to set the number closer to 0.1
+00:24:52.760 --> 00:24:55.039
+and then increase it twice
 
-25:19.520 --> 25:29.280
-another part of the users may actually try to optimize Emacs startup time which is quite frequent
+00:24:55.040 --> 00:24:58.639
+obviously you get twice less frequent gcs
 
-25:29.280 --> 25:37.200
-problem in this case it's probably better to increase gc constant but not too much so like
+00:24:58.640 --> 00:25:02.559
+but it will come at the cost of extra 10 percent gc time
 
-25:37.200 --> 25:42.640
-first of all it makes sense to check whether garbage collection is a problem at all during
+00:25:02.560 --> 00:25:05.839
+and if you increase 10 times you can think about
 
-25:43.520 --> 25:48.160
-startup and there are two variables which can show what is happening
+00:25:05.840 --> 00:25:08.719
+10 less 10 x less frequent gcs
 
-25:49.120 --> 25:54.800
-this garbage collection so gc done is a variable that shows how many garbage collection
+00:25:08.720 --> 00:25:12.199
+but almost twice longer individual garbage collection time
 
-25:57.520 --> 26:02.560
-like what is the number of garbage collections triggered like when you check the value or
+00:25:12.200 --> 00:25:16.919
+so probably you want to set the number closer to 0.1
 
-26:02.560 --> 26:08.320
-right after you start Emacs you will see that number and gc elapsed variable
+00:25:16.920 --> 00:25:23.399
+another part of the users may actually
 
-26:09.280 --> 26:15.440
-which gives you a number of seconds which Emacs spent in doing garbage collection so this is
+00:25:23.400 --> 00:25:28.359
+try to optimize Emacs startup time
 
-26:15.440 --> 26:20.800
-probably the most important variable and if you see it's large then you may consider tweaking it
+00:25:28.360 --> 00:25:30.759
+which is quite frequent problem
 
-26:20.800 --> 26:30.000
-for the Emacs startup we can estimate some bounds because in the statistics I never saw anything
+00:25:30.760 --> 00:25:34.919
+in this case it's probably better to increase gc constant
 
-26:30.000 --> 26:35.600
-that is more than 10 seconds extra which even 10 seconds is probably like a really really hard
+00:25:34.920 --> 00:25:38.199
+but not too much so like
 
-26:35.600 --> 26:45.280
-upper bound so or say if you want to decrease the gc contribution like order of magnitude
+00:25:38.200 --> 00:25:40.239
+first of all it makes sense to check
 
-26:45.920 --> 26:52.080
-or like two orders of magnitudes let's say like as a really hard top estimate then it
+00:25:40.240 --> 00:25:43.319
+whether garbage collection is a problem at all
 
-26:52.080 --> 27:00.080
-corresponds to 80 megabytes gc constant and probably much less so like there's no point
+00:25:43.320 --> 00:25:45.999
+during startup and there are two variables
 
-27:00.080 --> 27:06.880
-setting it to a few hundred megabytes of course there's one caveat which is important to keep in
+00:25:46.000 --> 00:25:50.199
+which can show what is happening this garbage collection
 
-27:06.880 --> 27:16.800
-mind though that increasing the gc thresholds is not just increasing individual gc time
+00:25:50.200 --> 00:25:53.719
+so gc done is a variable that shows
 
-27:16.800 --> 27:23.600
-there's also an actual real impact on the RAM usage so like if you increase gc threshold
+00:25:53.720 --> 00:25:55.039
+how many garbage collection
 
-27:24.400 --> 27:29.600
-it increases the RAM usage of Emacs and you shouldn't think that like okay I increased
+00:25:55.040 --> 00:26:00.159
+like what is the number of garbage collections triggered
 
-27:30.480 --> 27:37.200
-the threshold by like 100 megabytes then 100 megabytes extra RAM usage doesn't matter
+00:26:00.160 --> 00:26:02.599
+like when you check the value
 
-27:37.200 --> 27:44.480
-it's not 100 megabytes because less frequent garbage collection means it will lead to
+00:26:02.600 --> 00:26:04.039
+or right after you start Emacs
 
-27:44.480 --> 27:51.680
-memory fragmentation so in practice if you increase the thresholds to tens or hundreds
+00:26:04.040 --> 00:26:04.799
+you will see that
 
-27:51.680 --> 27:58.240
-of megabytes we are talking about gigabytes extra RAM usage for me personally when I tried to
+00:26:04.800 --> 00:26:08.519
+number and gc elapsed variable
 
-27:58.240 --> 28:05.200
-play with gc thresholds I have seen Emacs taking two gigabytes like compared to several times less
+00:26:08.520 --> 00:26:11.599
+which gives you a number of seconds
 
-28:05.760 --> 28:12.240
-when with default settings so it's not free at all and only like either when you have a lot of
+00:26:11.600 --> 00:26:14.959
+which Emacs spent in doing garbage collection
 
-28:12.240 --> 28:19.440
-free RAM and you don't care or when your Emacs is really slow then you may need to consider this
+00:26:14.960 --> 00:26:16.879
+so this is probably the most important variable
 
-28:19.440 --> 28:24.160
-tweaking these defaults so again don't tweak defaults if you don't really have a problem
+00:26:16.880 --> 00:26:20.719
+and if you see it's large then you may consider tweaking it
 
-28:24.800 --> 28:31.360
-and of course this RAM problem is a big big deal for Emacs devs because from
+00:26:20.720 --> 00:26:26.799
+for the Emacs startup we can estimate some bounds
 
-28:32.960 --> 28:38.400
-from the point of single user you have like normal laptop most likely like normal PC with a lot of
+00:26:26.800 --> 00:26:30.039
+because in the statistics I never saw anything
 
-28:38.400 --> 28:45.760
-RAM you don't care about these things too much but Emacs in general can run on like
+00:26:30.040 --> 00:26:32.439
+that is more than 10 seconds extra
 
-28:46.320 --> 28:53.200
-all kinds of machines including low-end machines with very limited RAM and anytime Emacs developers
+00:26:32.440 --> 00:26:34.439
+which even 10 seconds is probably like
 
-28:53.280 --> 29:00.320
-consider increasing the defaults for garbage collection it's like they always have to consider
+00:26:34.440 --> 00:26:39.119
+a really really hard upper bound so
 
-29:00.320 --> 29:06.800
-if you increase them too much then Emacs may just stop running on certain platforms
+00:26:39.120 --> 00:26:44.479
+or say if you want to decrease the gc contribution
 
-29:09.840 --> 29:15.600
-so that's a very big consideration in terms of the global defaults for everyone
+00:26:44.480 --> 00:26:47.479
+like order of magnitude or like two orders of magnitudes
 
-29:16.320 --> 29:24.560
-although I have to I would say that it might be related to the safe to increase GCCons threshold
+00:26:47.480 --> 00:26:50.879
+let's say like as a really hard top estimate
 
-29:24.560 --> 29:29.600
-because it mostly affects startup and during startup it's probably not the peak usage of
+00:26:50.880 --> 00:26:55.079
+then it corresponds to 80 megabytes gc constant
 
-29:30.560 --> 29:38.160
-Emacs and like as Emacs runs for longer it's probably where most of RAM will be used later
+00:26:55.080 --> 00:26:58.959
+and probably much less so like
 
-29:38.720 --> 29:43.920
-on the other hand GCCons percentage is much more debating because it has pros and cons
+00:26:58.960 --> 00:27:00.679
+there's no point setting it
 
-29:43.920 --> 29:48.880
-it will increase the RAM usage it will increase the individual GC time so
+00:27:00.680 --> 00:27:04.159
+to a few hundred megabytes of course
 
-29:50.240 --> 29:56.560
-if we consider changing it it's much more tricky and we have discussing probably measure the impact
+00:27:04.160 --> 00:27:08.439
+there's one caveat which is important to keep in
 
-29:56.560 --> 30:06.080
-on users and a final note on or from the point of view of Emacs development is that
+00:27:08.440 --> 00:27:14.039
+mind though that increasing the gc thresholds
 
-30:06.480 --> 30:11.440
-this simple mark-and-sweep algorithm is like a very old and not the state-of-the-art algorithm
+00:27:14.040 --> 00:27:16.399
+is not just increasing individual gc time
 
-30:13.040 --> 30:16.960
-there are variants of garbage collection that are like totally non-blocking
+00:27:16.400 --> 00:27:20.399
+there's also an actual real impact on the RAM usage
 
-30:18.000 --> 30:22.720
-so Emacs just doesn't have to freeze during the garbage collection or there are variants
+00:27:20.400 --> 00:27:23.839
+so like if you increase gc threshold
 
-30:22.720 --> 30:27.440
-of garbage collection algorithm that do not scan all the memory just fraction of it
+00:27:23.840 --> 00:27:26.879
+it increases the RAM usage of Emacs
 
-30:28.640 --> 30:35.520
-and scan another fraction less frequently so there are actually ways just to
+00:27:26.880 --> 00:27:29.639
+and you shouldn't think that like okay
 
-30:36.480 --> 30:39.680
-change the garbage collection algorithm to make things much faster
+00:27:29.640 --> 00:27:33.159
+I increased the threshold by like 100 megabytes
 
-30:40.400 --> 30:47.280
-of course like just changing the numbers of variables like the numbers of variable values
+00:27:33.160 --> 00:27:37.119
+then 100 megabytes extra RAM usage doesn't matter
 
-30:47.280 --> 30:52.000
-is much more tricky and one has to implement it obviously it would be nice if someone implements
+00:27:37.120 --> 00:27:38.679
+it's not 100 megabytes
 
-30:52.000 --> 30:58.720
-it but so far it's not happening so yeah it would be nice but maybe not not so quickly
+00:27:38.680 --> 00:27:42.319
+because less frequent garbage collection means
 
-30:59.600 --> 31:02.080
+00:27:42.320 --> 00:27:45.639
+it will lead to memory fragmentation
+
+00:27:45.640 --> 00:27:50.439
+so in practice if you increase the thresholds
+
+00:27:50.440 --> 00:27:52.799
+to tens or hundreds of megabytes
+
+00:27:52.800 --> 00:27:55.919
+we are talking about gigabytes extra RAM usage
+
+00:27:55.920 --> 00:27:59.719
+for me personally when I tried to play with gc thresholds
+
+00:27:59.720 --> 00:28:02.879
+I have seen Emacs taking two gigabytes like
+
+00:28:02.880 --> 00:28:05.519
+compared to several times less
+
+00:28:05.520 --> 00:28:09.039
+when with default settings so it's not free at all
+
+00:28:09.040 --> 00:28:13.639
+and only like either when you have a lot of free RAM
+
+00:28:13.640 --> 00:28:16.839
+and you don't care or when your Emacs is really slow
+
+00:28:16.840 --> 00:28:19.559
+then you may need to consider this
+
+00:28:19.560 --> 00:28:23.239
+tweaking these defaults so again don't tweak defaults
+
+00:28:23.240 --> 00:28:24.239
+if you don't really have a problem
+
+00:28:24.240 --> 00:28:29.839
+and of course this RAM problem is a big big deal
+
+00:28:29.840 --> 00:28:35.679
+for Emacs devs because from from the point of single user
+
+00:28:35.680 --> 00:28:38.839
+you have like normal laptop most likely like normal PC
+
+00:28:38.840 --> 00:28:42.079
+with a lot of RAM you don't care about these things too much
+
+00:28:42.080 --> 00:28:48.999
+but Emacs in general can run on like all kinds of machines
+
+00:28:49.000 --> 00:28:51.679
+including low-end machines with very limited RAM
+
+00:28:51.680 --> 00:28:55.359
+and anytime Emacs developers consider increasing
+
+00:28:55.360 --> 00:28:57.959
+the defaults for garbage collection
+
+00:28:57.960 --> 00:29:01.479
+it's like they always have to consider
+
+00:29:01.480 --> 00:29:02.959
+if you increase them too much
+
+00:29:02.960 --> 00:29:07.919
+then Emacs may just stop running on certain platforms
+
+00:29:07.920 --> 00:29:14.439
+so that's a very big consideration in terms
+
+00:29:14.440 --> 00:29:16.639
+of the global defaults for everyone
+
+00:29:16.640 --> 00:29:22.199
+although I have to I would say that it might be related
+
+00:29:22.200 --> 00:29:24.479
+to the safe to increase GCCons threshold
+
+00:29:24.480 --> 00:29:27.919
+because it mostly affects startup and during startup
+
+00:29:27.920 --> 00:29:31.279
+it's probably not the peak usage of Emacs
+
+00:29:31.280 --> 00:29:35.599
+and like as Emacs runs for longer
+
+00:29:35.600 --> 00:29:38.199
+it's probably where most of RAM will be used later
+
+00:29:38.200 --> 00:29:44.399
+on the other hand GCCons percentage is much more debating
+
+00:29:44.400 --> 00:29:46.159
+because it has pros and cons
+
+00:29:46.160 --> 00:29:47.719
+it will increase the RAM usage
+
+00:29:47.720 --> 00:29:50.999
+it will increase the individual GC time so
+
+00:29:51.000 --> 00:29:56.119
+if we consider changing it it's much more tricky
+
+00:29:56.120 --> 00:29:59.479
+and we have discussing probably measure the impact on users
+
+00:29:59.480 --> 00:30:05.799
+and a final note on or from the point of view
+
+00:30:05.800 --> 00:30:07.319
+of Emacs development is
+
+00:30:07.320 --> 00:30:11.039
+that this simple mark-and-sweep algorithm
+
+00:30:11.040 --> 00:30:14.119
+is like a very old and not the state-of-the-art algorithm
+
+00:30:14.120 --> 00:30:17.799
+there are variants of garbage collection
+
+00:30:17.800 --> 00:30:19.479
+that are like totally non-blocking
+
+00:30:19.480 --> 00:30:22.479
+so Emacs just doesn't have to freeze
+
+00:30:22.480 --> 00:30:24.279
+during the garbage collection
+
+00:30:24.280 --> 00:30:26.839
+or there are variants of garbage collection algorithm
+
+00:30:26.840 --> 00:30:30.079
+that do not scan all the memory just fraction of it
+
+00:30:30.080 --> 00:30:33.439
+and scan another fraction less frequently
+
+00:30:33.440 --> 00:30:36.999
+so there are actually ways just to change
+
+00:30:37.000 --> 00:30:39.799
+the garbage collection algorithm to make things much faster
+
+00:30:39.800 --> 00:30:44.199
+of course like just changing the numbers of variables
+
+00:30:44.200 --> 00:30:47.079
+like the numbers of variable values
+
+00:30:47.080 --> 00:30:50.079
+is much more tricky and one has to implement it
+
+00:30:50.080 --> 00:30:52.239
+obviously it would be nice if someone implements it
+
+00:30:52.240 --> 00:30:55.639
+but so far it's not happening so yeah it would be nice
+
+00:30:55.640 --> 00:30:59.359
+but maybe not not so quickly
+
+00:30:59.360 --> 00:31:02.159
 there is more chance to change the defaults here
 
-31:02.240 --> 31:05.680
+00:31:02.160 --> 00:31:07.479
 to conclude let me reiterate the most important points
 
-31:06.640 --> 31:12.400
-so from point of view of users you need to understand that yes garbage collection may be
+00:31:07.480 --> 00:31:11.919
+so from point of view of users you need to understand that
+
+00:31:11.920 --> 00:31:14.479
+yes garbage collection may be a problem
+
+00:31:14.480 --> 00:31:16.679
+but not for everyone so like
+
+00:31:16.680 --> 00:31:21.079
+you should only think about changing the variables
+
+00:31:21.080 --> 00:31:23.559
+when you really know that garbage collection
+
+00:31:23.560 --> 00:31:27.479
+is the problem for you so if you have slow Emacs startup
+
+00:31:27.480 --> 00:31:30.919
+slow Emacs startup and you know that it's caused by
+
+00:31:30.920 --> 00:31:32.479
+garbage collection like by
+
+00:31:32.480 --> 00:31:35.999
+you can check the GC elapsed variable
+
+00:31:36.000 --> 00:31:39.679
+then you may increase GC count threshold
+
+00:31:39.680 --> 00:31:42.119
+like to few tens of megabytes not more
+
+00:31:42.120 --> 00:31:44.479
+it doesn't make sense to increase it much more
+
+00:31:44.480 --> 00:31:48.239
+and if you really have major problems
+
+00:31:48.240 --> 00:31:49.759
+with Emacs being slaggy
+
+00:31:49.760 --> 00:31:52.519
+then you can increase GC count percentage
+
+00:31:52.520 --> 00:31:55.999
+to like 0.2 0.3 maybe
+
+00:31:56.000 --> 00:31:57.679
+one is probably overkill
+
+00:31:57.680 --> 00:32:02.759
+but do watch your Emacs ROM usage it may be really impacted
+
+00:32:02.760 --> 00:32:09.719
+for Emacs developers I'd like to emphasize
+
+00:32:09.720 --> 00:32:12.439
+that there is a real problem with garbage collection
+
+00:32:12.440 --> 00:32:17.959
+and nine percent of all the garbage collection
 
-31:12.400 --> 31:20.480
-a problem but not for everyone so like you should only think about changing the variables when you
+00:32:17.960 --> 00:32:22.079
+data points we have correspond
 
-31:20.480 --> 31:28.240
-really know that garbage collection is the problem for you so if you have slow Emacs startup
+00:32:22.080 --> 00:32:24.959
+to really slow noticeable Emacs precision
 
-31:28.400 --> 31:34.000
-slow Emacs startup and you know that it's caused by garbage collection like by you can check the
+00:32:24.960 --> 00:32:28.039
+and really frequent less than 10 seconds
 
-31:34.000 --> 31:41.520
-GC elapsed variable then you may increase GC count threshold like to few tens of megabytes
+00:32:28.040 --> 00:32:32.319
+I'd say that it's really worth
 
-31:41.520 --> 31:48.160
-not more it doesn't make sense to increase it much more and if you really have major problems
+00:32:32.320 --> 00:32:35.279
+increasing GC count threshold at least during startup
 
-31:48.160 --> 31:56.080
-with Emacs being slaggy then you can increase GC count percentage to like 0.2 0.3 maybe
+00:32:35.280 --> 00:32:40.159
+because it really impacts the Emacs startup time
 
-31:56.080 --> 32:02.640
-one is probably overkill but do watch your Emacs ROM usage it may be really impacted
+00:32:40.160 --> 00:32:41.519
+making Emacs startup much faster
 
-32:04.160 --> 32:12.400
-for Emacs developers I'd like to emphasize that there is a real problem with garbage collection
+00:32:41.520 --> 00:32:44.799
+ideally we need to reimplement
 
-32:12.400 --> 32:22.720
-and nine percent of all the garbage collection data points we have correspond to really slow
+00:32:44.800 --> 00:32:48.599
+the garbage collection algorithm of course it's not easy
 
-32:22.720 --> 32:27.920
-noticeable Emacs precision and really frequent less than 10 seconds
+00:32:48.600 --> 00:32:50.159
+but it would be really nice
 
-32:30.000 --> 32:35.120
-I'd say that it's really worth increasing GC count threshold at least during startup
+00:32:50.160 --> 00:32:56.399
+and for GC count percentage defaults it's hard to say
 
-32:36.400 --> 32:41.440
-because it really impacts the Emacs startup time making Emacs startup much faster
+00:32:56.400 --> 00:33:00.759
+we may consider changing it but it's up to discussion
 
-32:42.400 --> 32:48.560
-ideally we need to reimplement the garbage collection algorithm of course it's not easy
+00:33:00.760 --> 00:33:03.119
+and we probably need to be conservative here
 
-32:48.560 --> 32:56.880
-but it would be really nice and for GC count percentage defaults it's hard to say we may
+00:33:03.120 --> 00:33:06.039
+so we came to the end of my talk
 
-32:56.880 --> 33:03.040
-consider changing it but it's up to discussion and we probably need to be conservative here
+00:33:06.040 --> 00:33:09.319
+and this presentation
 
-33:04.320 --> 33:11.280
-so we came to the end of my talk and this presentation all the data will be available
+00:33:09.320 --> 00:33:11.839
+all the data will be available publicly
 
-33:11.280 --> 33:21.760
-publicly and you can reproduce all the statistic graphs if you wish and thank you for attention
+00:33:11.840 --> 00:33:17.079
+and you can reproduce all the statistic graphs if you wish
 
+00:33:17.080 --> 00:33:21.920
+and thank you for attention
diff --git a/2023/captions/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main--chapters.vtt b/2023/captions/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main--chapters.vtt
new file mode 100644
index 00000000..1179c72e
--- /dev/null
+++ b/2023/captions/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main--chapters.vtt
@@ -0,0 +1,44 @@
+WEBVTT
+
+
+00:00:00.000 --> 00:00:21.560
+Intro
+
+00:00:21.560 --> 00:01:02.560
+Diagrams
+
+00:01:03.320 --> 00:02:51.360
+eev
+
+00:02:51.360 --> 00:08:52.560
+Another figure
+
+00:08:52.560 --> 00:10:44.240
+eev-wconfig, magic, and black boxes
+
+00:10:44.240 --> 00:16:10.960
+Lua
+
+00:16:10.960 --> 00:19:19.822
+Object orientation in Lua
+
+00:19:19.823 --> 00:20:31.000
+My init file
+
+00:20:31.000 --> 00:25:28.280
+LaTeX and LuaLaTeX
+
+00:25:28.280 --> 00:26:30.879
+Manim
+
+00:26:30.880 --> 00:31:03.240
+Generating diagrams from REPLs
+
+00:31:03.240 --> 00:39:03.200
+Parsers
+
+00:39:03.200 --> 00:50:04.160
+ELpeg1.lua
+
+00:50:04.160 --> 00:59:26.040
+Building lists
diff --git a/2023/info/core-before.md b/2023/info/core-before.md
index 90a7afb8..ad1ad161 100644
--- a/2023/info/core-before.md
+++ b/2023/info/core-before.md
@@ -7,6 +7,6 @@ Status: Q&A to be extracted from the room recordings
 
 
 
-<div class="vid"><video controls preload="none" id="core-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 1:07:13 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.opus">Download --main.opus (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.webm">Download --main.webm (211MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/m4XmrmE9Geat54AKT1RQaH">View on Toobnix</a></li></ul></div></div>
+<div class="vid"><video controls preload="none" id="core-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 1:07:13 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.json">Download --main.json (2.4MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.opus">Download --main.opus (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.webm">Download --main.webm (211MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/m4XmrmE9Geat54AKT1RQaH">View on Toobnix</a></li></ul></div></div>
 # Description
 <!-- End of emacsconf-publish-before-page -->
\ No newline at end of file
diff --git a/2023/info/devel-before.md b/2023/info/devel-before.md
index 82342971..11f6df30 100644
--- a/2023/info/devel-before.md
+++ b/2023/info/devel-before.md
@@ -7,6 +7,6 @@ Status: Q&A to be extracted from the room recordings
 
 
 
-<div class="vid"><video controls preload="none" id="devel-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 23:22 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.opus">Download --main.opus (7.8MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.webm">Download --main.webm (38MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/57HSebb9a9JZynh2B3ehze">View on Toobnix</a></li></ul></div></div>
+<div class="vid"><video controls preload="none" id="devel-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 23:22 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.json">Download --main.json</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.opus">Download --main.opus (7.8MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.webm">Download --main.webm (38MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/57HSebb9a9JZynh2B3ehze">View on Toobnix</a></li></ul></div></div>
 # Description
 <!-- End of emacsconf-publish-before-page -->
\ No newline at end of file
diff --git a/2023/info/flat-before.md b/2023/info/flat-before.md
index 9ba28750..e960be0e 100644
--- a/2023/info/flat-before.md
+++ b/2023/info/flat-before.md
@@ -7,6 +7,6 @@ Status: Q&A to be extracted from the room recordings
 
 
 
-<div class="vid"><video controls preload="none" id="flat-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 22:20 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.opus">Download --main.opus (10MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.webm">Download --main.webm (121MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/1DRDY8vZK3SW5M8zAPJQSp">View on Toobnix</a></li></ul></div></div>
+<div class="vid"><video controls preload="none" id="flat-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 22:20 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.json">Download --main.json</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.opus">Download --main.opus (10MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.webm">Download --main.webm (121MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/1DRDY8vZK3SW5M8zAPJQSp">View on Toobnix</a></li></ul></div></div>
 # Description
 <!-- End of emacsconf-publish-before-page -->
\ No newline at end of file
diff --git a/2023/info/gc-after.md b/2023/info/gc-after.md
index eeb88a8f..d878219a 100644
--- a/2023/info/gc-after.md
+++ b/2023/info/gc-after.md
@@ -1,6 +1,610 @@
 <!-- Automatically generated by emacsconf-publish-after-page -->
 
 
+<a name="gc-mainVideo-transcript"></a>
+# Transcript
+
+
+[[!template new="1" text="""Introduction""" start="00:00:00.000" video="mainVideo-gc" id="subtitle"]]
+
+[[!template text="""Hello everyone, my name is Ihor Radchenko,""" start="00:00:00.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you may know me from Org Mailing List.""" start="00:00:04.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""However, today I'm not going to talk about Org Mode.""" start="00:00:07.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Today I'm going to talk about""" start="00:00:09.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Emacs performance and how it's affected""" start="00:00:11.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""by its memory management code.""" start="00:00:14.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""First, I will introduce the basic concepts""" start="00:00:19.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of Emacs memory management and what garbage collection is.""" start="00:00:21.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Then I will show you user statistics""" start="00:00:26.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""collected from volunteer users over the last half year""" start="00:00:30.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and I will end with some guidelines""" start="00:00:34.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""on how to tweak Emacs garbage collection customizations""" start="00:00:39.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to optimize Emacs performance""" start="00:00:44.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and when it's necessary or not to do.""" start="00:00:47.480" video="mainVideo-gc" id="subtitle"]]
+
+[[!template new="1" text="""About garbage collection in Emacs""" start="00:00:51.080" video="mainVideo-gc" id="subtitle"]]
+
+[[!template text="""Let's begin. What is garbage collection?""" start="00:00:51.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""To understand what is garbage collection,""" start="00:00:54.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we need to realize that anything you do in Emacs""" start="00:00:56.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is some kind of command. Any command is most likely""" start="00:00:59.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""running some Elisp code. Every time you run Elisp code,""" start="00:01:02.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you most likely need to locate certain memory in RAM.""" start="00:01:05.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Some of this memory is retained for a long time""" start="00:01:09.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and some of this memory is transient.""" start="00:01:12.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Of course, Emacs has to clear this transient memory""" start="00:01:15.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""from time to time, to not occupy all the possible RAM""" start="00:01:19.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""in the computer. In this small example,""" start="00:01:21.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we have one global variable""" start="00:01:21.448" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that is assigned a value,""" start="00:01:28.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but when assigning the value,""" start="00:01:31.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we first allocate a temporary variable""" start="00:01:33.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then a temporary list""" start="00:01:35.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and only retain some part of this list""" start="00:01:37.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""in this global variable.""" start="00:01:40.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""In terms of memory graph""" start="00:01:42.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we can represent this as two variable slots,""" start="00:01:44.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""one transient, one permanent,""" start="00:01:50.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then a list of three cons cells,""" start="00:01:53.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""part of which is retained as a global variable""" start="00:01:56.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but part of it which is a temporary variable symbol.""" start="00:02:01.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""The first term of the list is not used""" start="00:02:05.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and it might be cleared at some point.""" start="00:02:07.680" video="mainVideo-gc" id="subtitle"]]
+
+[[!template new="1" text="""Garbage collection in Emacs""" start="00:02:09.760" video="mainVideo-gc" id="subtitle"]]
+
+[[!template text="""So that's what Emacs does.""" start="00:02:09.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Every now and then, Emacs goes through all the memory""" start="00:02:12.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and identifies which part of the memory are not used""" start="00:02:15.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then clear them so that it can free up the RAM.""" start="00:02:19.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""This process is called garbage collection""" start="00:02:23.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and Emacs uses a very simple and old algorithm""" start="00:02:25.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is called Mark & Sweep.""" start="00:02:28.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So doing this mark and sweep process""" start="00:02:30.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is basically two stages.""" start="00:02:33.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""First, Emacs scans all the memory that is allocated""" start="00:02:34.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then identifies which memory is still in use""" start="00:02:40.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is linked to some variables, for example,""" start="00:02:42.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and which memory is not used anymore""" start="00:02:45.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""even though it was allocated in the past.""" start="00:02:47.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""The second stage [??] whenever a memory is not,""" start="00:02:49.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that is not allocated. During the process""" start="00:02:53.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Emacs cannot do anything now.""" start="00:02:59.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So basically, every time Emacs scans the memory,""" start="00:03:00.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it freezes up and doesn't respond to anything,""" start="00:03:04.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and if it takes too much time so that users can notice it,""" start="00:03:07.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then of course Emacs is not responsive at all,""" start="00:03:10.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and if this garbage collection is triggered too frequently,""" start="00:03:13.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then it's not just not responsive every now and then.""" start="00:03:19.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""It's also not responsive all the time,""" start="00:03:22.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""almost all the time,""" start="00:03:24.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so it cannot even normally type or stuff""" start="00:03:26.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or do some normal commands.""" start="00:03:27.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""This mark and sweep algorithm is taking longer""" start="00:03:32.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the more memory Emacs uses. So basically,""" start="00:03:36.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the more buffers you open, the more packages you load,""" start="00:03:40.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the more complex commands you run, the more memory is used,""" start="00:03:44.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and basically, the longer Emacs takes""" start="00:03:48.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to perform a single garbage collection.""" start="00:03:52.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Of course, Emacs being Emacs""" start="00:03:57.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""this garbage collection can be tweaked.""" start="00:04:02.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""In particular users can tweak""" start="00:04:06.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""how frequently Emacs does garbage collection""" start="00:04:08.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""using two basic variables: `gc-cons-threshold`""" start="00:04:10.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and `gc-cons-percentage`.""" start="00:04:13.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""`gc-cons-threshold` is the raw number of kilobytes""" start="00:04:15.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Emacs needs to allocate""" start="00:04:21.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""before triggering another garbage collection,""" start="00:04:22.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and the `gc-cons-percentage` is similar,""" start="00:04:25.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but it's defined in terms of fraction""" start="00:04:27.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of already-allocated memory.""" start="00:04:30.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""If you follow various Emacs forums,""" start="00:04:34.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you may be familiar with people complaining about""" start="00:04:38.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""garbage collection. There are many many suggestions""" start="00:04:41.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""about what to do with it.""" start="00:04:46.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Most frequently, you see `gc-cons-threshold`""" start="00:04:48.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""recommended to be increased,""" start="00:04:54.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and a number of pre-packaged Emacs distributions""" start="00:04:56.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like Doom Emacs do increase it.""" start="00:05:01.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""I have seen suggestions which are actually horrible""" start="00:05:04.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to disable garbage collection temporarily""" start="00:05:07.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or for a long time.""" start="00:05:10.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Which is nice... You can see it quite frequently,""" start="00:05:14.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which indicates there might be some problem.""" start="00:05:17.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""However, every time one user poses about this problem,""" start="00:05:19.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's just one data point and it doesn't mean""" start="00:05:23.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that everyone actually suffers from it.""" start="00:05:26.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""It doesn't mean that everyone should do it.""" start="00:05:28.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So in order to understand if this garbage collection""" start="00:05:33.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is really a problem which is a common problem""" start="00:05:35.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we do need some kind of statistics""" start="00:05:39.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and only using the actual statistics""" start="00:05:44.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we can understand if it should be recommended for everyone""" start="00:05:46.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to tweak the defaults or like whether""" start="00:05:52.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it should be recommended for certain users""" start="00:05:55.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or maybe it should be asked Emacs devs""" start="00:05:57.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to do something about the defaults.""" start="00:05:59.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And what I did some time ago is exactly this.""" start="00:06:01.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""I tried to collect the user statistics.""" start="00:06:07.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So I wrote a small package on Elp""" start="00:06:09.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and some users installed this package""" start="00:06:14.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then reported back these statistics""" start="00:06:18.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of the garbage collection for their particular use.""" start="00:06:22.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""By now we have obtained 129 user submissions""" start="00:06:24.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""with over 1 million GC records in there.""" start="00:06:30.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So like some of these submissions""" start="00:06:34.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""used default GC settings without any customizations.""" start="00:06:38.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Some used increased GC cost threshold""" start="00:06:43.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and GC cost percentage.""" start="00:06:46.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So using this data we can try to draw""" start="00:06:47.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""some reliable conclusions on what should be done""" start="00:06:53.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and whether should anything be done about garbage collection""" start="00:06:56.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""on Emacs dev level or at least on user level.""" start="00:06:59.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Of course we need to keep in mind""" start="00:07:02.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that there's some kind of bias""" start="00:07:05.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because it's more likely""" start="00:07:07.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that users already have problems with GC""" start="00:07:09.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or they think they have problems with GC""" start="00:07:11.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""will report and submit the data.""" start="00:07:13.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""But anyway having s statistics is much more useful""" start="00:07:15.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""than just having anecdotal evidences""" start="00:07:20.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""from one or other reddit posts.""" start="00:07:22.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And just one thing I will do""" start="00:07:25.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""during the rest of my presentation""" start="00:07:28.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is that for all the statistics""" start="00:07:30.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""I will normalize user data""" start="00:07:32.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so that every user contributes equally.""" start="00:07:35.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""For example if one user submits like""" start="00:07:37.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""100 hours Emacs uptime statistics""" start="00:07:40.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and other users submit one hour Emacs uptime""" start="00:07:43.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then I will anyway make it so that they contribute equally.""" start="00:07:46.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Let's start from one of the most obvious things""" start="00:07:52.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we can look into is""" start="00:07:56.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is the time it takes for garbage collection""" start="00:07:57.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to single garbage collection process.""" start="00:08:00.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Here you see frequency distribution of GC duration""" start="00:08:05.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""for all the 129 users we got""" start="00:08:11.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you can see that most of the garbage collections""" start="00:08:15.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""are done quite quickly in less than 0.1 second""" start="00:08:22.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and less than 0.1 second is usually just not noticeable.""" start="00:08:27.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So even though there is garbage collection""" start="00:08:32.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it will not interrupt the work in Emacs.""" start="00:08:34.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""However there is a fraction of users""" start="00:08:39.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""who experience garbage collection""" start="00:08:43.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it takes like 0.2, 0.3 or even half a second""" start="00:08:45.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which will be quite noticeable.""" start="00:08:48.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""For the purposes of this study""" start="00:08:50.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""I will consider that anything that is less than 0.1 second""" start="00:08:55.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is insignificant so like you will not notice it""" start="00:08:59.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and it's like obviously""" start="00:09:02.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""all the Emacs usage will be just normal.""" start="00:09:04.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""But if it's more than 0.1 or 0.2 seconds""" start="00:09:07.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then it will be very noticeable""" start="00:09:11.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you will see that Emacs hang for a little while""" start="00:09:13.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or not so little while. In terms of numbers""" start="00:09:16.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's better to plot the statistics not as a distribution""" start="00:09:21.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but as a cumulative distribution.""" start="00:09:26.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So like at every point of this graph""" start="00:09:28.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you'll see like for example here 0.4 seconds""" start="00:09:31.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you have this percent of like almost 90% of users""" start="00:09:37.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""have no more than 0.4 gc duration.""" start="00:09:42.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So like we can look here if we take one""" start="00:09:49.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""gc critical gc duration which is 0.1 second""" start="00:09:53.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""0.1 second and look at how many users have""" start="00:09:56.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it so we have 56% which is like""" start="00:10:00.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""44% users have less than 0.1 second gc duration""" start="00:10:02.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and the rest 56% have more than 0.1 second.""" start="00:10:09.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So you can see like more than half of users""" start="00:10:12.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""actually have noticeable gc delay""" start="00:10:16.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so the Emacs freezes for some noticeable time""" start="00:10:20.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and a quarter of users actually have very noticeable""" start="00:10:23.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so like Emacs freezes such that you see an actual delay""" start="00:10:27.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that Emacs actually has""" start="00:10:31.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is quite significant and important point.""" start="00:10:36.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""But apart from the duration of each individual gc""" start="00:10:44.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it is important to see how frequent it is""" start="00:10:47.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because even if you do notice a delay""" start="00:10:49.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""even a few seconds delay""" start="00:10:52.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it doesn't matter if it happens once""" start="00:10:54.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""during the whole Emacs session.""" start="00:10:57.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So if you look into frequency distribution again here""" start="00:10:59.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""I plot time between subsequent garbage collections""" start="00:11:05.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""versus how frequent it is and we have very clear trend""" start="00:11:13.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that most of the garbage collections are quite frequent""" start="00:11:17.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like we talk about every few seconds a few tens of seconds.""" start="00:11:21.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""There's a few outliers which are at very round numbers""" start="00:11:25.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like 60 seconds, 120 seconds, 300 seconds.""" start="00:11:30.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""These are usually timers so like""" start="00:11:35.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you have something running on timer""" start="00:11:37.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then it is complex command""" start="00:11:40.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and it triggers garbage collection""" start="00:11:43.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but it's not the majority.""" start="00:11:45.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Again to run the numbers""" start="00:11:48.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's better to look into cumulative distribution""" start="00:11:51.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and see that 50% of garbage collections""" start="00:11:53.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""are basically less than 10 seconds apart.""" start="00:11:56.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And we can combine it with previous data""" start="00:11:58.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and we look into whatever garbage collection""" start="00:12:02.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""takes less than 10 seconds from each other""" start="00:12:07.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and also takes more than say 0.1 seconds.""" start="00:12:09.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So and then we see that""" start="00:12:13.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""one quarter of all garbage collections""" start="00:12:15.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""are just noticeable and also frequent""" start="00:12:17.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and 9% are not like""" start="00:12:21.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""more than 0.2% very noticeable and also frequent.""" start="00:12:23.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So basically it constitutes Emacs freezing.""" start="00:12:27.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So 9% of all the garbage collection Emacs freezing.""" start="00:12:30.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Of course if you remember there is a bias""" start="00:12:33.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but 9% is quite significant number.""" start="00:12:37.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So garbage collection can really slow down things""" start="00:12:40.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""not for everyone but for significant fraction of users.""" start="00:12:44.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Another thing I'd like to look into""" start="00:12:48.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is what I call agglomerated GCs.""" start="00:12:52.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""What I mean by agglomerated is""" start="00:12:55.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""when you have one garbage collection""" start="00:12:57.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then another garbage immediately after it.""" start="00:13:00.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So in terms of numbers I took""" start="00:13:03.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""every subsequent garbage collection""" start="00:13:05.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is either immediately after""" start="00:13:08.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or no more than one second after each.""" start="00:13:10.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So from point of view of users is like""" start="00:13:13.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""multiple garbage collection they add up together""" start="00:13:16.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""into one giant garbage collection.""" start="00:13:20.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And if you look into numbers""" start="00:13:23.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of how many agglomerated garbage collections there are""" start="00:13:25.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you can see even numbers over 100.""" start="00:13:29.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So 100 garbage collection going one after another.""" start="00:13:32.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Even if you think about each garbage collection""" start="00:13:35.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""taking 0.1 second we look into 100 of them""" start="00:13:39.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's total 10 seconds.""" start="00:13:42.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""It's like Emacs hanging forever""" start="00:13:44.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or like a significant number is also 10.""" start="00:13:46.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So again this would be very annoying to meet such thing.""" start="00:13:53.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""How frequently does it happen?""" start="00:13:56.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Again we can plot cumulative distribution""" start="00:13:57.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and we see that 20 percent like 19 percent""" start="00:14:00.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of all the garbage collection are at least two together""" start="00:14:03.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and 8 percent like more than 10. So like you think about oh""" start="00:14:07.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""each garbage collection is not taking much time""" start="00:14:13.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but when you have 10 of them yeah that becomes a problem.""" start="00:14:15.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Another thing is to answer a question""" start="00:14:24.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that some people complain about is that""" start="00:14:29.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""longer you use Emacs the slower Emacs become.""" start="00:14:32.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Of course it may be caused by garbage collection""" start="00:14:35.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and I wanted to look into how garbage collection time""" start="00:14:43.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and other statistics,""" start="00:14:48.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""other parameters are evolving over time.""" start="00:14:49.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And what I can see here is a cumulative distribution""" start="00:14:53.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of GC duration for like first 10 minutes of Emacs uptime""" start="00:14:58.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""first 100 minutes first 1000 minutes.""" start="00:15:03.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And if you look closer then you see""" start="00:15:06.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that each individual garbage collection on average""" start="00:15:10.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""takes longer as you use Emacs longer.""" start="00:15:14.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""However this longer is not much it's like maybe 10 percent""" start="00:15:18.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like basically garbage collection gets like""" start="00:15:24.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""slow Emacs down more as you use Emacs more but not much.""" start="00:15:29.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So basically if you do you see Emacs""" start="00:15:34.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""being slower and slower over time""" start="00:15:38.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's probably not really garbage collection""" start="00:15:40.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because it doesn't change too much.""" start="00:15:43.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And if you look into time""" start="00:15:45.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""between individual garbage collections""" start="00:15:48.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you see that the time actually increases""" start="00:15:50.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""as you use Emacs longer which makes sense""" start="00:15:53.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because initially like first few minutes""" start="00:15:56.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you have all kind of packages loading""" start="00:15:58.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like all the port loading and then later""" start="00:16:01.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""everything is loaded and things become more stable.""" start="00:16:04.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So the conclusion on this part is that""" start="00:16:07.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""if Emacs becomes slower in a long session""" start="00:16:12.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's probably not caused by garbage collection.""" start="00:16:16.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And one word of warning of course is that""" start="00:16:18.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's all nice and all when I present the statistics""" start="00:16:23.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but it's only an average""" start="00:16:27.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and if you are an actual user like here is one example""" start="00:16:29.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which shows a total garbage collection time""" start="00:16:34.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like accumulated together over Emacs uptime""" start="00:16:37.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you see different lines""" start="00:16:40.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which correspond to different sessions of one user""" start="00:16:43.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you see they are wildly different""" start="00:16:45.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like one time there is almost no garbage collection""" start="00:16:48.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""another time you see garbage collection""" start="00:16:51.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because probably Emacs is used more early""" start="00:16:54.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or like different pattern of usage""" start="00:16:57.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and even during a single Emacs session""" start="00:16:59.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you see a different slope""" start="00:17:03.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of this curve which means that""" start="00:17:04.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""sometimes garbage collection is infrequent""" start="00:17:06.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and sometimes it's much more frequent""" start="00:17:09.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so it's probably much more noticeable one time""" start="00:17:11.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and less noticeable other time.""" start="00:17:14.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""So if you think about these statistics of course""" start="00:17:15.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""they only represent an average usage""" start="00:17:19.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but sometimes it can get worse sometimes it can get better.""" start="00:17:23.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""The last parameter I'd like to talk about is""" start="00:17:26.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""garbage collection during Emacs init.""" start="00:17:33.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Basically if you think about what happens during Emacs init""" start="00:17:35.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like when Emacs just starting up""" start="00:17:40.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then whatever garbage collection""" start="00:17:41.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""there it's one or it's several times""" start="00:17:44.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it all contributes to Emacs taking longer to start.""" start="00:17:46.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""And again we can look into the statistic""" start="00:17:51.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and see what is the total GC duration after Emacs init""" start="00:17:56.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and we see that 50% of all the submissions""" start="00:18:01.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""garbage collection adds up more than one second""" start="00:18:06.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to Emacs init time and for 20% of users""" start="00:18:10.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's extra three seconds Emacs start time""" start="00:18:14.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is very significant""" start="00:18:17.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""especially for people who are used to Vim""" start="00:18:18.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which can start in like a fraction of a second""" start="00:18:21.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and here it just does garbage collection""" start="00:18:23.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because garbage collection is not""" start="00:18:26.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""everything Emacs does during startup""" start="00:18:27.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""adds up more to the load.""" start="00:18:29.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Okay that's all nice and all""" start="00:18:32.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but what can we do about these statistics""" start="00:18:36.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""can we draw any conclusions""" start="00:18:38.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and the answer is of course""" start="00:18:40.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like the most important conclusion here is that""" start="00:18:43.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""yes garbage collection can slow down Emacs""" start="00:18:46.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""at least for some people and what to do about it""" start="00:18:49.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""there are two variables which you can tweak""" start="00:18:52.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's because gcconce threshold gcconce percentage""" start="00:18:55.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and having the statistics I can at least look a little bit""" start="00:18:58.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""into what is the effect of increasing these variables""" start="00:19:03.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like most people just increase gcconce threshold""" start="00:19:08.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and like all the submissions people did increase""" start="00:19:12.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and doesn't make much sense to decrease it""" start="00:19:16.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like to make things worse""" start="00:19:19.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of course for these statistics""" start="00:19:21.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the exact values of this increased thresholds""" start="00:19:27.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""are not always the same""" start="00:19:31.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but at least we can look into some trends""" start="00:19:33.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so first and obvious thing we can observe""" start="00:19:36.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is when we compare""" start="00:19:44.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the standard gc settings standard thresholds""" start="00:19:46.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and increased thresholds for time between""" start="00:19:50.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""subsequent gcs and as one may expect""" start="00:19:54.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""if you increase the threshold""" start="00:19:57.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Emacs will do garbage collection less frequently""" start="00:19:59.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so the spacing between garbage collection increases""" start="00:20:02.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""okay the only thing is that""" start="00:20:05.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""if garbage collection is less frequent""" start="00:20:07.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then each individual garbage collection becomes longer""" start="00:20:10.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so if you think about increasing""" start="00:20:14.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""garbage collection thresholds be prepared""" start="00:20:18.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that in each individual time Emacs freezes will take longer""" start="00:20:22.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""this is one caveat when we talk about""" start="00:20:26.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""this agglomerated gcs which are one after other""" start="00:20:31.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like if you increase the threshold sufficiently""" start="00:20:34.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then whatever happened that garbage collections""" start="00:20:36.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""were like done one after other""" start="00:20:42.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we can now make it so that they are actually separated""" start="00:20:44.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so like you don't see one giant freeze caused by""" start="00:20:47.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like 10 gcs in a row""" start="00:20:51.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""instead you can make it so that they are separated""" start="00:20:52.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and in statistics it's very clear""" start="00:20:55.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that the number of agglomerated garbage collections""" start="00:20:59.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""decreases dramatically when you increase the thresholds""" start="00:21:02.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's particularly evident when we look into startup time""" start="00:21:06.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""if you look at gc duration during Emacs startup""" start="00:21:11.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and if we look into what happens""" start="00:21:17.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""when you increase the thresholds""" start="00:21:19.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's very clear that Emacs startup become faster""" start="00:21:20.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""when you increase gc thresholds""" start="00:21:23.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so that's all for actual user statistics""" start="00:21:26.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and now let's try to run into""" start="00:21:33.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""some like actual recommendations""" start="00:21:35.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""on what numbers to set and before we start""" start="00:21:38.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""let me explain a little bit about""" start="00:21:42.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the difference between these two variables""" start="00:21:44.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is gc constant threshold and gc constant percentage""" start="00:21:46.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so if you think about Emacs memory""" start="00:21:48.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like there's a certain memory allocated by Emacs""" start="00:21:52.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then as you run commands and turn using Emacs""" start="00:21:55.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""there is more memory allocated""" start="00:21:58.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and Emacs decides when to do garbage collection""" start="00:22:00.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""according these two variables""" start="00:22:04.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and actually what it does it chooses the larger one""" start="00:22:06.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so say you have you are late in Emacs session""" start="00:22:08.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you have a lot of Emacs memory allocated""" start="00:22:12.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then you have gc constant percentage""" start="00:22:14.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is percent of the already allocated memory""" start="00:22:17.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and that percent is probably going to be the largest""" start="00:22:19.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because you have more memory""" start="00:22:25.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and memory means that percent of it is larger""" start="00:22:28.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so like you have a larger number cost""" start="00:22:32.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""by gc constant percentage""" start="00:22:36.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so in this scenario when Emacs session is already running""" start="00:22:37.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""for a long time and there is a lot of memory allocated""" start="00:22:43.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you have gc constant percentage""" start="00:22:45.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""controlling the garbage collection""" start="00:22:50.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""while early in Emacs there is not much memory placed""" start="00:22:52.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""Emacs just starting up then gc constant threshold""" start="00:22:55.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is controlling how frequently garbage collection happens""" start="00:22:58.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because smaller allocated memory""" start="00:23:01.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""means its percentage will be a small number""" start="00:23:04.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so in terms of default values at least""" start="00:23:06.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""gc constant threshold is 800 kilobytes""" start="00:23:12.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and gc constant percentage is 10""" start="00:23:14.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so gc constant percentage becomes larger than that threshold""" start="00:23:18.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""when you have more than eight megabytes of allocated memory""" start="00:23:24.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""by Emacs which is quite early""" start="00:23:28.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and it will probably hold just during the startup""" start="00:23:31.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and once you start using your maximum""" start="00:23:34.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and once you load all the histories""" start="00:23:36.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""all the kinds of buffers it's probably going to take""" start="00:23:38.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""more than much more than eight megabytes""" start="00:23:42.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so now we understand this""" start="00:23:43.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we can draw certain recommendations""" start="00:23:50.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""about tweaking the gc thresholds""" start="00:23:53.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so first of all I need to emphasize""" start="00:23:57.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that any time you increase gc threshold""" start="00:24:01.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""an individual garbage collection time increases""" start="00:24:03.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so it's not free at all""" start="00:24:07.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""if you don't have problems with garbage collection""" start="00:24:08.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is half of the users don't have much problem""" start="00:24:11.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you don't need to tweak anything""" start="00:24:13.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""only when gc is frequent and slow""" start="00:24:15.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""when Emacs is really really present frequently""" start="00:24:19.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you may consider increasing gc thresholds only""" start="00:24:23.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and in particular I recommend""" start="00:24:27.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""increasing gc constant percentage""" start="00:24:31.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because that's what mostly controls gc""" start="00:24:33.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""when Emacs is running for long session""" start="00:24:36.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and the numbers are probably like""" start="00:24:40.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""yeah we can estimate the effect of these numbers""" start="00:24:43.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like for example if you have a default value of 0.1 percent""" start="00:24:46.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""for gc constant percentage 0.1 which is 10 percent""" start="00:24:49.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and then increase it twice""" start="00:24:52.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""obviously you get twice less frequent gcs""" start="00:24:55.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but it will come at the cost of extra 10 percent gc time""" start="00:24:58.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and if you increase 10 times you can think about""" start="00:25:02.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""10 less 10 x less frequent gcs""" start="00:25:05.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but almost twice longer individual garbage collection time""" start="00:25:08.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so probably you want to set the number closer to 0.1""" start="00:25:12.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""another part of the users may actually""" start="00:25:16.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""try to optimize Emacs startup time""" start="00:25:23.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which is quite frequent problem""" start="00:25:28.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""in this case it's probably better to increase gc constant""" start="00:25:30.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but not too much so like""" start="00:25:34.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""first of all it makes sense to check""" start="00:25:38.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""whether garbage collection is a problem at all""" start="00:25:40.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""during startup and there are two variables""" start="00:25:43.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which can show what is happening this garbage collection""" start="00:25:46.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so gc done is a variable that shows""" start="00:25:50.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""how many garbage collection""" start="00:25:53.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like what is the number of garbage collections triggered""" start="00:25:55.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like when you check the value""" start="00:26:00.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or right after you start Emacs""" start="00:26:02.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you will see that""" start="00:26:04.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""number and gc elapsed variable""" start="00:26:04.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which gives you a number of seconds""" start="00:26:08.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which Emacs spent in doing garbage collection""" start="00:26:11.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so this is probably the most important variable""" start="00:26:14.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and if you see it's large then you may consider tweaking it""" start="00:26:16.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""for the Emacs startup we can estimate some bounds""" start="00:26:20.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because in the statistics I never saw anything""" start="00:26:26.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that is more than 10 seconds extra""" start="00:26:30.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""which even 10 seconds is probably like""" start="00:26:32.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""a really really hard upper bound so""" start="00:26:34.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or say if you want to decrease the gc contribution""" start="00:26:39.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like order of magnitude or like two orders of magnitudes""" start="00:26:44.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""let's say like as a really hard top estimate""" start="00:26:47.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then it corresponds to 80 megabytes gc constant""" start="00:26:50.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and probably much less so like""" start="00:26:55.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""there's no point setting it""" start="00:26:58.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to a few hundred megabytes of course""" start="00:27:00.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""there's one caveat which is important to keep in""" start="00:27:04.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""mind though that increasing the gc thresholds""" start="00:27:08.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is not just increasing individual gc time""" start="00:27:14.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""there's also an actual real impact on the RAM usage""" start="00:27:16.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so like if you increase gc threshold""" start="00:27:20.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it increases the RAM usage of Emacs""" start="00:27:23.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you shouldn't think that like okay""" start="00:27:26.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""I increased the threshold by like 100 megabytes""" start="00:27:29.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then 100 megabytes extra RAM usage doesn't matter""" start="00:27:33.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's not 100 megabytes""" start="00:27:37.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because less frequent garbage collection means""" start="00:27:38.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it will lead to memory fragmentation""" start="00:27:42.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so in practice if you increase the thresholds""" start="00:27:45.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to tens or hundreds of megabytes""" start="00:27:50.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we are talking about gigabytes extra RAM usage""" start="00:27:52.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""for me personally when I tried to play with gc thresholds""" start="00:27:55.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""I have seen Emacs taking two gigabytes like""" start="00:27:59.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""compared to several times less""" start="00:28:02.880" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""when with default settings so it's not free at all""" start="00:28:05.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and only like either when you have a lot of free RAM""" start="00:28:09.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you don't care or when your Emacs is really slow""" start="00:28:13.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then you may need to consider this""" start="00:28:16.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""tweaking these defaults so again don't tweak defaults""" start="00:28:19.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""if you don't really have a problem""" start="00:28:23.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and of course this RAM problem is a big big deal""" start="00:28:24.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""for Emacs devs because from from the point of single user""" start="00:28:29.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you have like normal laptop most likely like normal PC""" start="00:28:35.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""with a lot of RAM you don't care about these things too much""" start="00:28:38.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but Emacs in general can run on like all kinds of machines""" start="00:28:42.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""including low-end machines with very limited RAM""" start="00:28:49.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and anytime Emacs developers consider increasing""" start="00:28:51.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the defaults for garbage collection""" start="00:28:55.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's like they always have to consider""" start="00:28:57.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""if you increase them too much""" start="00:29:01.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then Emacs may just stop running on certain platforms""" start="00:29:02.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so that's a very big consideration in terms""" start="00:29:07.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of the global defaults for everyone""" start="00:29:14.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""although I have to I would say that it might be related""" start="00:29:16.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to the safe to increase GCCons threshold""" start="00:29:22.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because it mostly affects startup and during startup""" start="00:29:24.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's probably not the peak usage of Emacs""" start="00:29:27.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and like as Emacs runs for longer""" start="00:29:31.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it's probably where most of RAM will be used later""" start="00:29:35.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""on the other hand GCCons percentage is much more debating""" start="00:29:38.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because it has pros and cons""" start="00:29:44.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it will increase the RAM usage""" start="00:29:46.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it will increase the individual GC time so""" start="00:29:47.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""if we consider changing it it's much more tricky""" start="00:29:51.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and we have discussing probably measure the impact on users""" start="00:29:56.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and a final note on or from the point of view""" start="00:29:59.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of Emacs development is""" start="00:30:05.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that this simple mark-and-sweep algorithm""" start="00:30:07.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is like a very old and not the state-of-the-art algorithm""" start="00:30:11.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""there are variants of garbage collection""" start="00:30:14.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that are like totally non-blocking""" start="00:30:17.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so Emacs just doesn't have to freeze""" start="00:30:19.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""during the garbage collection""" start="00:30:22.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""or there are variants of garbage collection algorithm""" start="00:30:24.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that do not scan all the memory just fraction of it""" start="00:30:26.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and scan another fraction less frequently""" start="00:30:30.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so there are actually ways just to change""" start="00:30:33.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the garbage collection algorithm to make things much faster""" start="00:30:37.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""of course like just changing the numbers of variables""" start="00:30:39.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like the numbers of variable values""" start="00:30:44.200" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is much more tricky and one has to implement it""" start="00:30:47.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""obviously it would be nice if someone implements it""" start="00:30:50.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but so far it's not happening so yeah it would be nice""" start="00:30:52.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but maybe not not so quickly""" start="00:30:55.640" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""there is more chance to change the defaults here""" start="00:30:59.360" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to conclude let me reiterate the most important points""" start="00:31:02.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so from point of view of users you need to understand that""" start="00:31:07.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""yes garbage collection may be a problem""" start="00:31:11.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but not for everyone so like""" start="00:31:14.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you should only think about changing the variables""" start="00:31:16.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""when you really know that garbage collection""" start="00:31:21.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""is the problem for you so if you have slow Emacs startup""" start="00:31:23.560" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""slow Emacs startup and you know that it's caused by""" start="00:31:27.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""garbage collection like by""" start="00:31:30.920" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""you can check the GC elapsed variable""" start="00:31:32.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then you may increase GC count threshold""" start="00:31:36.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""like to few tens of megabytes not more""" start="00:31:39.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""it doesn't make sense to increase it much more""" start="00:31:42.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and if you really have major problems""" start="00:31:44.480" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""with Emacs being slaggy""" start="00:31:48.240" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""then you can increase GC count percentage""" start="00:31:49.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to like 0.2 0.3 maybe""" start="00:31:52.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""one is probably overkill""" start="00:31:56.000" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but do watch your Emacs ROM usage it may be really impacted""" start="00:31:57.680" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""for Emacs developers I'd like to emphasize""" start="00:32:02.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""that there is a real problem with garbage collection""" start="00:32:09.720" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and nine percent of all the garbage collection""" start="00:32:12.440" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""data points we have correspond""" start="00:32:17.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""to really slow noticeable Emacs precision""" start="00:32:22.080" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and really frequent less than 10 seconds""" start="00:32:24.960" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""I'd say that it's really worth""" start="00:32:28.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""increasing GC count threshold at least during startup""" start="00:32:32.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""because it really impacts the Emacs startup time""" start="00:32:35.280" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""making Emacs startup much faster""" start="00:32:40.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""ideally we need to reimplement""" start="00:32:41.520" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""the garbage collection algorithm of course it's not easy""" start="00:32:44.800" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""but it would be really nice""" start="00:32:48.600" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and for GC count percentage defaults it's hard to say""" start="00:32:50.160" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""we may consider changing it but it's up to discussion""" start="00:32:56.400" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and we probably need to be conservative here""" start="00:33:00.760" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""so we came to the end of my talk""" start="00:33:03.120" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and this presentation""" start="00:33:06.040" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""all the data will be available publicly""" start="00:33:09.320" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and you can reproduce all the statistic graphs if you wish""" start="00:33:11.840" video="mainVideo-gc" id="subtitle"]]
+[[!template text="""and thank you for attention""" start="00:33:17.080" video="mainVideo-gc" id="subtitle"]]
+
 Questions or comments? Please e-mail [yantar92@posteo.net](mailto:yantar92@posteo.net?subject=Comment%20for%20EmacsConf%202023%20gc%3A%20emacs-gc-stats%3A%20Does%20garbage%20collection%20actually%20slow%20down%20Emacs%3F)
 
 
diff --git a/2023/info/gc-before.md b/2023/info/gc-before.md
index 26982303..2ccee0ad 100644
--- a/2023/info/gc-before.md
+++ b/2023/info/gc-before.md
@@ -7,6 +7,6 @@ Status: Q&A to be extracted from the room recordings
 
 
 
-<div class="vid"><video controls preload="none" id="gc-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 33:22 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.opus">Download --main.opus (22MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.webm">Download --main.webm (80MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/ngenUPBLDDkZGmsxK8vimJ">View on Toobnix</a></li></ul></div></div>
+<div class="vid"><video controls preload="none" id="gc-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.webm" />captions="""<track label="English" kind="captions" srclang="en" src="/2023/captions/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt" default />"""<p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 33:22 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.opus">Download --main.opus (22MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.webm">Download --main.webm (80MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/ngenUPBLDDkZGmsxK8vimJ">View on Toobnix</a></li></ul></div></div>
 # Description
 <!-- End of emacsconf-publish-before-page -->
\ No newline at end of file
diff --git a/2023/info/koutline-before.md b/2023/info/koutline-before.md
index 44f141a5..cd62982a 100644
--- a/2023/info/koutline-before.md
+++ b/2023/info/koutline-before.md
@@ -7,6 +7,6 @@ Status: Q&A to be extracted from the room recordings
 
 
 
-<div class="vid"><video controls preload="none" id="koutline-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 06:44 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.opus">Download --main.opus (4.5MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.webm">Download --main.webm (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/vV7qtK176DVE6RLXrZ18Ee">View on Toobnix</a></li></ul></div></div>
+<div class="vid"><video controls preload="none" id="koutline-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 06:44 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.json">Download --main.json</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.opus">Download --main.opus (4.5MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.webm">Download --main.webm (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/vV7qtK176DVE6RLXrZ18Ee">View on Toobnix</a></li></ul></div></div>
 # Description
 <!-- End of emacsconf-publish-before-page -->
\ No newline at end of file
diff --git a/2023/info/repl-before.md b/2023/info/repl-before.md
index dccbc016..c26e7c44 100644
--- a/2023/info/repl-before.md
+++ b/2023/info/repl-before.md
@@ -7,6 +7,22 @@ Status: Q&A to be extracted from the room recordings
 
 
 
-<div class="vid"><video controls preload="none" id="repl-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main.webm" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video><div></div>Duration: 59:10 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main.opus">Download --main.opus (29MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main.webm">Download --main.webm (187MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/oAjqkLNfo9B63EE1G6cJJV">View on Toobnix</a></li></ul></div></div>
+<div class="vid"><video controls preload="none" id="repl-mainVideo"><source src="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main.webm" /><track kind="chapters" label="Chapters" src="/2023/captions/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main--chapters.vtt" /><p><em>Your browser does not support the video tag. Please download the video instead.</em></p></video>[[!template id="chapters" vidid="repl-mainVideo" data="""
+00:00.000 Intro
+00:21.560 Diagrams
+01:03.320 eev
+02:51.360 Another figure
+08:52.560 eev-wconfig, magic, and black boxes
+10:44.240 Lua
+16:10.960 Object orientation in Lua
+19:19.823 My init file
+20:31.000 LaTeX and LuaLaTeX
+25:28.280 Manim
+26:30.880 Generating diagrams from REPLs
+31:03.240 Parsers
+39:03.200 ELpeg1.lua
+50:04.160 Building lists
+
+"""]]<div></div>Duration: 59:10 minutes<div class="files resources"><ul><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main.opus">Download --main.opus (29MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--main.webm">Download --main.webm (187MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-repl--repls-in-strange-places-lua-latex-lpeg-lpegrex-tikz--eduardo-ochs--pad.md">Download --pad.md</a></li><li><a href="https://toobnix.org/w/oAjqkLNfo9B63EE1G6cJJV">View on Toobnix</a></li></ul></div></div>
 # Description
 <!-- End of emacsconf-publish-before-page -->
\ No newline at end of file
diff --git a/2023/schedule-details.md b/2023/schedule-details.md
index 42e2f6fb..2a2d3c62 100644
--- a/2023/schedule-details.md
+++ b/2023/schedule-details.md
@@ -22,9 +22,9 @@ Jump to: <a href="#date-2023-12-02">Sat Dec 2</a> - <a href="#date-2023-12-03">S
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--main.ogg">Download --main.ogg (7.9MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--main.opus">Download --main.opus (7.8MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--main.webm">Download --main.webm (38MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-ref--orgmode-workflow-informal-reference-tracking--christopher-howard--pad.md">Download --pad.md</a></li>""" title="""Org-Mode workflow: informal reference tracking""" url="""/2023/talks/ref""" speakers="""Christopher Howard""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""ref""" note="""captioned, video posted, video: 15:04"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--answers.opus">Download --answers.opus (18MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--answers.webm">Download --answers.webm (69MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--main.opus">Download --main.opus (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--main.webm">Download --main.webm (133MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-doc--literate-documentation-with-emacs-and-org-mode--mike-hamrick--pad.md">Download --pad.md</a></li>""" title="""Literate Documentation with Emacs and Org Mode""" url="""/2023/talks/doc""" speakers="""Mike Hamrick""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""doc""" note="""captioned, video posted, video: 42:45, answers: 11:00"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-unentangling--unentangling-projects-and-repos--alexey-bochkarev--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-unentangling--unentangling-projects-and-repos--alexey-bochkarev--main.opus">Download --main.opus (10MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-unentangling--unentangling-projects-and-repos--alexey-bochkarev--main.webm">Download --main.webm (68MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-unentangling--unentangling-projects-and-repos--alexey-bochkarev--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-unentangling--unentangling-projects-and-repos--alexey-bochkarev--pad.md">Download --pad.md</a></li>""" title="""(Un)entangling projects and repos""" url="""/2023/talks/unentangling""" speakers="""Alexey Bochkarev""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""unentangling""" note="""video posted, video: 12:39"""]]
-[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.opus">Download --main.opus (7.8MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.webm">Download --main.webm (38MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--pad.md">Download --pad.md</a></li>""" title="""Emacs development updates""" url="""/2023/talks/devel""" speakers="""John Wiegley""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""devel""" note="""video posted, video: 23:22"""]]
+[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.json">Download --main.json</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.opus">Download --main.opus (7.8MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--main.webm">Download --main.webm (38MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-devel--emacs-development-updates--john-wiegley--pad.md">Download --pad.md</a></li>""" title="""Emacs development updates""" url="""/2023/talks/devel""" speakers="""John Wiegley""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""devel""" note="""video posted, video: 23:22"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-windows--windows-into-freedom--corwin-brust--answers.opus">Download --answers.opus (29MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-windows--windows-into-freedom--corwin-brust--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-windows--windows-into-freedom--corwin-brust--main.opus">Download --main.opus (29MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-windows--windows-into-freedom--corwin-brust--main.webm">Download --main.webm (80MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-windows--windows-into-freedom--corwin-brust--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-windows--windows-into-freedom--corwin-brust--pad.md">Download --pad.md</a></li>""" title="""Windows into Freedom""" url="""/2023/talks/windows""" speakers="""Corwin Brust""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""windows""" note="""video posted, video: 57:48"""]]
-[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.opus">Download --main.opus (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.webm">Download --main.webm (211MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--pad.md">Download --pad.md</a></li>""" title="""Emacs core development: how it works""" url="""/2023/talks/core""" speakers="""Stefan Kangas""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""core""" note="""video posted, video: 1:07:13"""]]
+[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.json">Download --main.json (2.4MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.opus">Download --main.opus (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--main.webm">Download --main.webm (211MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-core--emacs-core-development-how-it-works--stefan-kangas--pad.md">Download --pad.md</a></li>""" title="""Emacs core development: how it works""" url="""/2023/talks/core""" speakers="""Stefan Kangas""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""core""" note="""video posted, video: 1:07:13"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sat-close--saturday-closing-remarks--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sat-close--saturday-closing-remarks--main.opus">Download --main.opus (4.7MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sat-close--saturday-closing-remarks--main.webm">Download --main.webm (32MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sat-close--saturday-closing-remarks--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sat-close--saturday-closing-remarks--pad.md">Download --pad.md</a></li>""" title="""Saturday closing remarks""" url="""/2023/talks/sat-close""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""sat-close""" note="""video posted, video: 09:00"""]]</div>
 
 Jump to: <a href="#date-2023-12-02">Sat Dec 2</a> - <a href="#date-2023-12-03">Sun Dec 3</a><a name="date-2023-12-03"></a>
@@ -34,17 +34,17 @@ Jump to: <a href="#date-2023-12-02">Sat Dec 2</a> - <a href="#date-2023-12-03">S
 <div class="schedule" data-start="2023-12-03T14:00:00+0000" data-end="2023-12-03T22:30:00+0000" data-tracks="General,Development">
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sun-open--sunday-opening-remarks--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sun-open--sunday-opening-remarks--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sun-open--sunday-opening-remarks--main.opus">Download --main.opus (2.5MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sun-open--sunday-opening-remarks--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sun-open--sunday-opening-remarks--main.webm">Download --main.webm (12MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sun-open--sunday-opening-remarks--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-sun-open--sunday-opening-remarks--pad.md">Download --pad.md</a></li>""" title="""Sunday opening remarks""" url="""/2023/talks/sun-open""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""sun-open""" note="""captioned, video posted, video: 05:17"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperamp--top-10-ways-hyperbole-amps-up-emacs--robert-weiner--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperamp--top-10-ways-hyperbole-amps-up-emacs--robert-weiner--main.opus">Download --main.opus (37MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperamp--top-10-ways-hyperbole-amps-up-emacs--robert-weiner--main.webm">Download --main.webm (234MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperamp--top-10-ways-hyperbole-amps-up-emacs--robert-weiner--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperamp--top-10-ways-hyperbole-amps-up-emacs--robert-weiner--pad.md">Download --pad.md</a></li>""" title="""Top 10 ways Hyperbole amps up Emacs""" url="""/2023/talks/hyperamp""" speakers="""Robert Weiner""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""hyperamp""" note="""video posted, video: 1:05:16"""]]
-[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.opus">Download --main.opus (4.5MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.webm">Download --main.webm (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--pad.md">Download --pad.md</a></li>""" title="""Using Koutline for stream of thought journaling""" url="""/2023/talks/koutline""" speakers="""Matthew Jorgensen (PlasmaStrike)""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""koutline""" note="""video posted, video: 06:44"""]]
+[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.json">Download --main.json</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.opus">Download --main.opus (4.5MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--main.webm">Download --main.webm (23MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-koutline--using-koutline-for-stream-of-thought-journaling--matthew-jorgensen-plasmastrike--pad.md">Download --pad.md</a></li>""" title="""Using Koutline for stream of thought journaling""" url="""/2023/talks/koutline""" speakers="""Matthew Jorgensen (PlasmaStrike)""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""koutline""" note="""video posted, video: 06:44"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--answers.opus">Download --answers.opus (5.1MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--answers.webm">Download --answers.webm (57MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--main.opus">Download --main.opus (14MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--main.webm">Download --main.webm (54MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-scheme--bringing-joy-to-scheme-programming--andrew-tropin--pad.md">Download --pad.md</a></li>""" title="""Bringing joy to Scheme programming""" url="""/2023/talks/scheme""" speakers="""Andrew Tropin""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""scheme""" note="""captioned, video posted, video: 21:01"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--answers.opus">Download --answers.opus (6.8MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--answers.webm">Download --answers.webm (10MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main-vp8.webm">Download --main-vp8.webm (95MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.opus">Download --main.opus</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--main.webm">Download --main.webm (29MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-parallel--parallel-text-replacement--lovro-valentino-picotti--pad.md">Download --pad.md</a></li>""" title="""Parallel text replacement""" url="""/2023/talks/parallel""" speakers="""Lovro, Valentino Picotti""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""parallel""" note="""captioned, video posted, video: 14:46, answers: 10:16"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-eat--eat-and-eat-powered-eshell-fast-featureful-terminal-inside-emacs--akib-azmain-turja--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-eat--eat-and-eat-powered-eshell-fast-featureful-terminal-inside-emacs--akib-azmain-turja--main.opus">Download --main.opus</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-eat--eat-and-eat-powered-eshell-fast-featureful-terminal-inside-emacs--akib-azmain-turja--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-eat--eat-and-eat-powered-eshell-fast-featureful-terminal-inside-emacs--akib-azmain-turja--main.webm">Download --main.webm (39MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-eat--eat-and-eat-powered-eshell-fast-featureful-terminal-inside-emacs--akib-azmain-turja--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-eat--eat-and-eat-powered-eshell-fast-featureful-terminal-inside-emacs--akib-azmain-turja--pad.md">Download --pad.md</a></li>""" title="""Eat and Eat powered Eshell, fast featureful terminal inside Emacs""" url="""/2023/talks/eat""" speakers="""Akib Azmain Turja""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""eat""" note="""video posted, video: 08:13"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--answers.opus">Download --answers.opus (4.2MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--answers.webm">Download --answers.webm (38MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--main.opus">Download --main.opus (9.3MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--main.webm">Download --main.webm (66MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-world--gnu-emacs-a-world-of-possibilities--anand-tamariya--pad.md">Download --pad.md</a></li>""" title="""GNU Emacs: A World of Possibilities""" url="""/2023/talks/world""" speakers="""Anand Tamariya""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""world""" note="""captioned, video posted, video: 20:31"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-poltys--the-browser-in-a-buffer--michael-bauer--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-poltys--the-browser-in-a-buffer--michael-bauer--main.opus">Download --main.opus (20MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-poltys--the-browser-in-a-buffer--michael-bauer--main.webm">Download --main.webm (185MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-poltys--the-browser-in-a-buffer--michael-bauer--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-poltys--the-browser-in-a-buffer--michael-bauer--pad.md">Download --pad.md</a></li>""" title="""The browser in a buffer""" url="""/2023/talks/poltys""" speakers="""Michael Bauer""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""poltys""" note="""video posted, video: 34:30"""]]
-[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.opus">Download --main.opus (10MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.webm">Download --main.webm (121MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--pad.md">Download --pad.md</a></li>""" title="""A modern Emacs look-and-feel without pain""" url="""/2023/talks/flat""" speakers="""Pedro A. Aranda""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""flat""" note="""video posted, video: 22:20"""]]
+[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.json">Download --main.json</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.opus">Download --main.opus (10MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--main.webm">Download --main.webm (121MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-flat--a-modern-emacs-lookandfeel-without-pain--pedro-a-aranda--pad.md">Download --pad.md</a></li>""" title="""A modern Emacs look-and-feel without pain""" url="""/2023/talks/flat""" speakers="""Pedro A. Aranda""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""flat""" note="""video posted, video: 22:20"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--alternative.webm">Download --alternative.webm (16MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--main.opus">Download --main.opus (8.6MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--main.vtt.diff">Download --main.vtt.diff</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--main.webm">Download --main.webm (57MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--pad.md">Download --pad.md</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--presentation.webm">Download --presentation.webm (16MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann--solve-demo.webm">Download --solve-demo.webm (11MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-cubing--speedcubing-in-emacs--vasilij-wasamasa-schneidermann.pdf">Download .pdf</a></li>""" title="""Speedcubing in Emacs""" url="""/2023/talks/cubing""" speakers="""wasamasa""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""cubing""" note="""captioned, video posted, video: 13:35"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--answers.opus">Download --answers.opus (39MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--answers.webm">Download --answers.webm (253MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--main.opus">Download --main.opus (11MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--main.webm">Download --main.webm (32MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emacsen--the-emacsen-family-the-design-of-an-emacs-and-the-importance-of-lisp--fermin--pad.md">Download --pad.md</a></li>""" title="""The Emacsen family, the design of an Emacs and the importance of Lisp""" url="""/2023/talks/emacsen""" speakers="""Fermin""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""emacsen""" note="""captioned, video posted, video: 18:28, answers: 1:08:14"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--answers.opus">Download --answers.opus (19MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--answers.webm">Download --answers.webm (52MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main--chapters.vtt">Download --main--chapters.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.opus">Download --main.opus (21MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--main.webm">Download --main.webm (139MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin--pad.md">Download --pad.md</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-emms--emacs-multimedia-system-emms--yoni-rabkin.outline">Download .outline</a></li>""" title="""Emacs MultiMedia System (EMMS)""" url="""/2023/talks/emms""" speakers="""Yoni Rabkin""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""emms""" note="""captioned, video posted, video: 38:38, answers: 32:38"""]]
-[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.opus">Download --answers.opus (11MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.webm">Download --answers.webm (115MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.opus">Download --main.opus (22MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.webm">Download --main.webm (80MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--pad.md">Download --pad.md</a></li>""" title="""emacs-gc-stats: Does garbage collection actually slow down Emacs?""" url="""/2023/talks/gc""" speakers="""Ihor Radchenko""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""gc""" note="""video posted, video: 33:22"""]]
+[[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.opus">Download --answers.opus (11MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--answers.webm">Download --answers.webm (115MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.opus">Download --main.opus (22MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--main.webm">Download --main.webm (80MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-gc--emacsgcstats-does-garbage-collection-actually-slow-down-emacs--ihor-radchenko--pad.md">Download --pad.md</a></li>""" title="""emacs-gc-stats: Does garbage collection actually slow down Emacs?""" url="""/2023/talks/gc""" speakers="""Ihor Radchenko""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""gc""" note="""video posted, video: 33:22"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--answers.opus">Download --answers.opus (9MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--answers.webm">Download --answers.webm (48MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--intro.webm">Download --intro.webm (996kB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--main.opus">Download --main.opus (18MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--main.webm">Download --main.webm (149MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-hyperdrive--hyperdriveel-peertopeer-filesystem-in-emacs--joseph-turner--pad.md">Download --pad.md</a></li>""" title="""hyperdrive.el: Peer-to-peer filesystem in Emacs""" url="""/2023/talks/hyperdrive""" speakers="""Joseph Turner and Protesilaos Stavrou""" watch="""https://emacsconf.org/2023/watch/dev""" slug="""hyperdrive""" note="""captioned, video posted, video: 40:03, answers: 28:15"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-steno--programming-with-steno--daniel-alejandro-tapia--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-steno--programming-with-steno--daniel-alejandro-tapia--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-steno--programming-with-steno--daniel-alejandro-tapia--main.opus">Download --main.opus (13MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-steno--programming-with-steno--daniel-alejandro-tapia--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-steno--programming-with-steno--daniel-alejandro-tapia--main.webm">Download --main.webm (66MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-steno--programming-with-steno--daniel-alejandro-tapia--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-steno--programming-with-steno--daniel-alejandro-tapia--pad.md">Download --pad.md</a></li>""" title="""Programming with steno""" url="""/2023/talks/steno""" speakers="""Daniel Alejandro Tapia""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""steno""" note="""captioned, video posted, video: 25:03"""]]
 [[!template id=sched resources="""<li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--answers--trimmed.webm">Download --answers--trimmed.webm (176MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--answers.opus">Download --answers.opus (25MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--answers.webm">Download --answers.webm (176MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--intro.vtt">Download --intro.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--intro.webm">Download --intro.webm</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--main.opus">Download --main.opus (6.2MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--main.vtt">Download --main.vtt</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--main.webm">Download --main.webm (26MB)</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--pad.html">Download --pad.html</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen--pad.md">Download --pad.md</a></li><li><a href="https://media.emacsconf.org/2023/emacsconf-2023-mentor--mentoring-vscoders-as-an-emacsian-or-how-to-show-not-tell-people-about-the-wonders-of-emacs--jeremy-friesen.pdf">Download .pdf</a></li>""" title="""Mentoring VS-Coders as an Emacsian (or How to show not tell people about the wonders of Emacs)""" url="""/2023/talks/mentor""" speakers="""Jeremy Friesen""" watch="""https://emacsconf.org/2023/watch/gen""" slug="""mentor""" note="""captioned, video posted, video: 10:44, answers: 1:13:43"""]]
diff --git a/2023/talks/windows.md b/2023/talks/windows.md
index 2e7a213e..ed062231 100644
--- a/2023/talks/windows.md
+++ b/2023/talks/windows.md
@@ -9,6 +9,14 @@
 # Windows into Freedom
 Corwin Brust (He/Him) - Core-win Brew-st, IRC: corwin, <mailto:corwin@bru.st>
 
+[[!template id="help"
+summary="main talk does not have captions"
+tags="help_with_main_captions"
+message="""This talk does not have captions yet.
+Would you like to help [caption this talk](/captioning)?
+You may be able to start with these [autogenerated captions](/2023/captions/emacsconf-2023-windows--windows-into-freedom--corwin-brust--main.vtt)."""]]
+
+
 [[!inline pages="internal(2023/info/windows-before)" raw="yes"]]
 
 -   A Brief History of the windows port