From 2b47dac39b443210eb0d34ac31257f19c4ab1a64 Mon Sep 17 00:00:00 2001 From: Sacha Chua Date: Thu, 2 Dec 2021 12:46:03 -0500 Subject: Add pad stuff --- 2021/talks/faster.md | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) (limited to '2021/talks/faster.md') 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 | 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: + - + - + - + - +- 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: + + or +   +- +- +- \"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. +- + [[!inline pages="internal(2021/captions/faster)" raw="yes"]] [[!inline pages="internal(2021/info/faster-nav)" raw="yes"]] -- cgit v1.2.3