Video tweaks, removed slashes too

1 files changed, 18 insertions, 18 deletions

diff --git a/2021/talks/faster.md b/2021/talks/faster.md
index 220a715d..0434db61 100644
--- a/2021/talks/faster.md
+++ b/2021/talks/faster.md
@@ -33,18 +33,18 @@ 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
+    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
+    "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..\"
+    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>
@@ -55,7 +55,7 @@ Pad:
     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
+-   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
@@ -65,7 +65,7 @@ Pad:
 -   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?
+    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
@@ -73,14 +73,14 @@ Pad:
     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
+        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
+    -   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
+    -   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:
@@ -114,17 +114,17 @@ Links:
     <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!\"
+-   "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)
+-   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
+-   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>