Add pad stuff

1 files changed, 75 insertions, 0 deletions

diff --git a/2021/talks/faster.md b/2021/talks/faster.md
index e8a13489..220a715d 100644
--- a/2021/talks/faster.md
+++ b/2021/talks/faster.md
@@ -30,6 +30,59 @@ Preferred contact info | <dgutov@yandex.ru>
 
 IRC nick: dgutov
 
+Pad:
+
+-   Q1: Why are overlays slow compared to text-properties? I (believe
+    to) understand that it is (in part only?) due to \"get element n in
+    vector vs list\". If so, then why don\'t we change that? There could
+    be a text-property called \"overlays\", so that lookup would also be
+    like in a vector. What benefits does the datastructure currently
+    used for overlays have that make that undesirable? Would a mixed
+    approach make sense; i.e. allow non-modifiyng lookups to use the
+    \"cached\" overlays that are stored in the \"overlay\" text-property
+    and make text-inserting and overlay-moving actions store in the
+    currently used datastructure as well as in the indirect
+    text-property=\>overlay cache?
+    -   A: \"There is a pending patch to represent the set of a
+        buffer\'s overlays as an AAtree or somesuch..\"
+    -   Sounds promising :)
+    -   For more details, check out these threads:
+    -   <https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00616.html>
+    -   <https://lists.gnu.org/archive/html/emacs-devel/2016-11/msg00475.html>
+    -   <https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00565.html>
+    -   <https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00115.html>
+-   Q2: As a non-programmer, would these sorts of optimizations be
+    helpful to do on a personal init.el file?
+    -   A: Probably not
+    -   Though too much mode-line customisation may slow things down.
+-   Q3: What\'s a good approach for benchmarking destructive
+    operations?  If you delete elements from a list in-place, all
+    subsequent runs will be artificially fast.
+    -   A: There is an example of a comparison between operations from
+        different libraries in the example file provided by the talk.
+        Particularly check the benchmarks for delete and remove
+        operations (destructive and non-destructive, respectively).
+-   Q4:Cl-lib constructors, getters, and setters usually expand into
+    multiple levels of let-bindings. AFAIU, every let-binding is an
+    extra memory allocation. Do you recommend avoiding cl-defstruct in
+    favour of \"pure\" lists/vectors?
+    -   A: basically no. if defstruct allows you to organise better, go
+        ahead.
+-   Q5: Is it possible to optimize some emacs packages by making use of
+    code compiled from other languages (like C or Common Lisp) ((i.e. in
+    the same way python is able to import C code))?
+    -   A: yes emacs modules allow you to run C or Rust, transitioning
+        between emacs proper and module (passing the data) might slow
+        things down? Because of copying that\'s necessary to avoid
+        issues with gc.
+-   Q6:You mentioned that overlays are much slower compared to text
+    properties. What about text properties vs. buffer-local variables to
+    store position cache?
+    -   A: I haven\'t measured it but offhand I\'m going to guess that
+        buffer-local variables will be faster.
+    -   Also depends on the structure you\'re going to use for the
+        cache - is it a single cons, or a list, or a tree, etc.
+
 BBB:
 
 - AVL tree
@@ -53,6 +106,28 @@ IRC:
 - For more info about the performance of overlays vs text properties data structure, there's an Emacs TODO about it. C-h C-t and search for "Move overlays to intervals.c".
 - cl-defstruct getters/setters have compiler macros that expand into simple aref calls on vectors, they are very efficient
 
+Links:
+
+-   you might find the this bench-multi-lexical macro useful:
+    <https://alphapapa.github.io/emacs-package-dev-handbook/#outline-container-Optimization>
+    or
+    <https://github.com/alphapapa/emacs-package-dev-handbook#bench-multi-lexical> 
+-   <https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/elp.el>
+-   <https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/emacs-lisp/benchmark.el>
+-   \"Use hash tables kids!\"
+-   PSA: buffer-local-value is generally much faster than
+    with-current-buffer if all you need to do is get the value of a
+    variable in a buffer 
+-   EIEIO\'s object construction is slow because it goes through
+    \`make-instance\` which is a generic function and it itself calls
+    various other generic functions, so there\'s a lot of cl-generic
+    dispatch overhead; and then there\'s the fact that the (keyword)
+    arguments are laboriously parsed at run-time so it itself is slow as
+    well.
+-   There is a pending patch to represent the set of a buffer\'s
+    overlays as an AAtree or somesuch.
+-   <https://media.emacsconf.org/2021/emacsconf-2021-faster--optimizing-emacs-lisp-code--dmitry-gutov.el>
+
 [[!inline pages="internal(2021/captions/faster)" raw="yes"]]
 
 [[!inline pages="internal(2021/info/faster-nav)" raw="yes"]]