Emacs-30 performances

Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 560 bytes --]


Hello,

I am using my own package Psession to save my emacs sessions, variables,
history, all my buffers etc...  In all previous emacs versions since emacs-23
saving all when quitting Emacs was taking between 3 to 5 seconds more or
less, now with Emacs-30 it is nearly instant, incredibly fast.
I was wondering what have changed to reach such performances, it is not
native compilation, Emacs without it is as fast (at least for this).
The internal functions involved are `prin1`, `eval-when-compile` and
`compile-file`.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Date: Sun, 02 Jun 2024 14:52:48 +0000
> 
> I am using my own package Psession to save my emacs sessions, variables,
> history, all my buffers etc...  In all previous emacs versions since emacs-23
> saving all when quitting Emacs was taking between 3 to 5 seconds more or
> less, now with Emacs-30 it is nearly instant, incredibly fast.
> I was wondering what have changed to reach such performances

Hard to say without knowing what your package does to save the data,
let alone see the profile in the previous versions.  But maybe this is
commit bf00762745c (bug#70036)?  Or maybe commits aa0037aaf7c and
b7a737ef49e (bug#66117)?

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1926 bytes --]


Thanks Eli for your answer.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Date: Sun, 02 Jun 2024 14:52:48 +0000
>> 
>> I am using my own package Psession to save my emacs sessions, variables,
>> history, all my buffers etc...  In all previous emacs versions since emacs-23
>> saving all when quitting Emacs was taking between 3 to 5 seconds more or
>> less, now with Emacs-30 it is nearly instant, incredibly fast.
>> I was wondering what have changed to reach such performances
>
> Hard to say without knowing what your package does to save the data,
> let alone see the profile in the previous versions.

Each object is saved to its own compiled file.
The relevant part is this:

--8<---------------cut here---------------start------------->8---
      (with-temp-file file
        ;; Fix Emacs-30 lexbind warnings. 
        (insert ";;; -*- lexical-binding: t -*-\n")
        (prin1 `(setq-default ,obj (eval-when-compile ,obj)) (current-buffer)))
      (byte-compile-file file)
--8<---------------cut here---------------end--------------->8---

Perhaps this commit?

--8<---------------cut here---------------start------------->8---
commit 9bcc9690a8076a22398c27a7ccf836ee95eb16a2
Author: Mattias Engdegård <mattiase@acm.org>
Date:   Tue Jan 30 17:55:19 2024 +0100

    Eliminate lazy bytecode loading
    
    The obsolete lazy-loaded bytecode feature, enabled by
    `byte-compile-dynamic`, slows down Lisp execution even when not in use
    because every call to a bytecode function has to check that function
    for laziness.
--8<---------------cut here---------------end--------------->8---


> But maybe this is commit bf00762745c (bug#70036)?  Or maybe commits
> aa0037aaf7c and b7a737ef49e (bug#66117)?

I don't think these commits are related.

Anyway thanks and congratulations for this improvement.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Mattias Engdegård]

3 juni 2024 kl. 19.37 skrev Thierry Volpiatto <thievol@posteo.net>:

>      (with-temp-file file
>        ;; Fix Emacs-30 lexbind warnings. 
>        (insert ";;; -*- lexical-binding: t -*-\n")
>        (prin1 `(setq-default ,obj (eval-when-compile ,obj)) (current-buffer)))
>      (byte-compile-file file)

We have made small changes to several of the moving parts here but it's unclear how they have the outsized effect you reported.

> Perhaps this commit?

I wish! But it could be useful to find what actually did. If you had the time to bisect master to find it, or provide a self-contained benchmark for someone else to do it, then we might actually learn something of interest.

Finally an excuse to try git --term-good=bad --term-bad=good ...

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 3 juni 2024 kl. 19.37 skrev Thierry Volpiatto <thievol@posteo.net>:
>
>>      (with-temp-file file
>>        ;; Fix Emacs-30 lexbind warnings. 
>>        (insert ";;; -*- lexical-binding: t -*-\n")
>>        (prin1 `(setq-default ,obj (eval-when-compile ,obj)) (current-buffer)))
>>      (byte-compile-file file)
>
> We have made small changes to several of the moving parts here but it's unclear how they have the outsized effect you reported.
>
>> Perhaps this commit?
>
> I wish! But it could be useful to find what actually did. If you had
> the time to bisect master to find it,

I will do that when I find some time and provide the result
here.

> or provide a self-contained benchmark for someone else to do it, then
> we might actually learn something of interest.

Not sure to be able to provide this as we have not the same variables
and values but one can easily see the
difference by saving its emacs session in emacs-29 and emacs-30 by
evaling (psession--dump-object-to-file-save-alist) after customizing
some variables in psession, this will make a directory in .emacs.d
containing several *.elc files (no need to enable psession-mode for this).

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 3 juni 2024 kl. 19.37 skrev Thierry Volpiatto <thievol@posteo.net>:
>
>>      (with-temp-file file
>>        ;; Fix Emacs-30 lexbind warnings. 
>>        (insert ";;; -*- lexical-binding: t -*-\n")
>>        (prin1 `(setq-default ,obj (eval-when-compile ,obj)) (current-buffer)))
>>      (byte-compile-file file)
>
> We have made small changes to several of the moving parts here but it's unclear how they have the outsized effect you reported.
>
>> Perhaps this commit?
>
> I wish! But it could be useful to find what actually did. If you had
> the time to bisect master to find it,

I finally found:

--8<---------------cut here---------------start------------->8---
;; ae8f815613c  Sun Mar 24 14:37:03 2024 Update files for Emacs 29.3 Eli Zaretskii  (tag: emacs-29.3)
(benchmark-run 1 (psession--dump-object-to-file-save-alist))
(8.715188143 0 0.0)
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
;; 83a6e80d66a  Mon Mar 25 03:13:44 2024 (byte-optimize-form-code-walker): Simplify a bit Stefan Monnier 
(benchmark-run 1 (psession--dump-object-to-file-save-alist))
(0.259306895 0 0.0)
--8<---------------cut here---------------end--------------->8---

So it is the first change after emacs-29.3 tag, done by Stefan, even if
small, it makes a huge difference as you can see above (not sure to
understand why though :-)).

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/emacs-lisp/byte-opt.el b/lisp/emacs-lisp/byte-opt.el
index f6df40a2d9b..54997205edb 100644
--- a/lisp/emacs-lisp/byte-opt.el
+++ b/lisp/emacs-lisp/byte-opt.el
@@ -482,9 +482,6 @@ There can be multiple entries for the same NAME if it has several aliases.")
          (push name byte-optimize--dynamic-vars)
          `(,fn ,name . ,optimized-rest)))
 
-      (`(,(pred byte-code-function-p) . ,exps)
-       (cons fn (mapcar #'byte-optimize-form exps)))
-
       ((guard (when for-effect
 		(if-let ((tmp (byte-opt--fget fn 'side-effect-free)))
 		    (or byte-compile-delete-errors
--8<---------------cut here---------------end--------------->8---


-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

Thierry Volpiatto <thievol@posteo.net> writes:

> Mattias Engdegård <mattias.engdegard@gmail.com> writes:
>
>> 3 juni 2024 kl. 19.37 skrev Thierry Volpiatto <thievol@posteo.net>:
>>
>>>      (with-temp-file file
>>>        ;; Fix Emacs-30 lexbind warnings. 
>>>        (insert ";;; -*- lexical-binding: t -*-\n")
>>>        (prin1 `(setq-default ,obj (eval-when-compile ,obj)) (current-buffer)))
>>>      (byte-compile-file file)
>>
>> We have made small changes to several of the moving parts here but it's unclear how they have the outsized effect you reported.
>>
>>> Perhaps this commit?
>>
>> I wish! But it could be useful to find what actually did. If you had
>> the time to bisect master to find it,

> So it is the first change after emacs-29.3 tag, done by Stefan, even if
> small, it makes a huge difference as you can see above (not sure to
> understand why though :-)).

No I was wrong, this commit has nothing to do with this, it is much more
complex than this as the tags are on another line of development (AFAIU).

Here what I find:

Bad:
ea5fd375bb2  Sat Mar 4 11:16:51 2023 Fix documentation of 'normal-mode' in buffers that don't v.. Eli Zaretskii 
(benchmark-run 1 (psession--dump-object-to-file-save-alist))
(7.966819985 0 0.0)

Good:
396f46d904a  Thu Feb 16 16:07:55 2023 bug#61489: Increase BLOCK_ALIGN from 1024 to 32768           Konstantin Kharlamov 
(benchmark-run 1 (psession--dump-object-to-file-save-alist))
(0.488145912 0 0.0)

So this commit is perhaps the first commit where Emacs starts to be
fast, I am unsure because I don't fully understand how Emacs is
developed i.e. Master <=> emacs-29.


-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Eli Zaretskii]

> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: Mattias Engdegård <mattias.engdegard@gmail.com>,  Eli
>  Zaretskii
>  <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sun, 09 Jun 2024 06:41:45 +0000
> 
> 
> Here what I find:
> 
> Bad:
> ea5fd375bb2  Sat Mar 4 11:16:51 2023 Fix documentation of 'normal-mode' in buffers that don't v.. Eli Zaretskii 
> (benchmark-run 1 (psession--dump-object-to-file-save-alist))
> (7.966819985 0 0.0)
> 
> Good:
> 396f46d904a  Thu Feb 16 16:07:55 2023 bug#61489: Increase BLOCK_ALIGN from 1024 to 32768           Konstantin Kharlamov 
> (benchmark-run 1 (psession--dump-object-to-file-save-alist))
> (0.488145912 0 0.0)
> 
> So this commit is perhaps the first commit where Emacs starts to be
> fast, I am unsure because I don't fully understand how Emacs is
> developed i.e. Master <=> emacs-29.

How is emacs-29 relevant here?  The above commit 396f46d904a was
installed on master, AFAICT.

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: Mattias Engdegård <mattias.engdegard@gmail.com>,  Eli
>>  Zaretskii
>>  <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Sun, 09 Jun 2024 06:41:45 +0000
>> 
>> 
>> Here what I find:
>> 
>> Bad:
>> ea5fd375bb2  Sat Mar 4 11:16:51 2023 Fix documentation of 'normal-mode' in buffers that don't v.. Eli Zaretskii 
>> (benchmark-run 1 (psession--dump-object-to-file-save-alist))
>> (7.966819985 0 0.0)
>> 
>> Good:
>> 396f46d904a  Thu Feb 16 16:07:55 2023 bug#61489: Increase BLOCK_ALIGN from 1024 to 32768           Konstantin Kharlamov 
>> (benchmark-run 1 (psession--dump-object-to-file-save-alist))
>> (0.488145912 0 0.0)
>> 
>> So this commit is perhaps the first commit where Emacs starts to be
>> fast, I am unsure because I don't fully understand how Emacs is
>> developed i.e. Master <=> emacs-29.
>
> How is emacs-29 relevant here?

It is not, but initially I checked out the commit tagged emacs-29.3 and
started from there, which was stupid, of course the first commit after it
was good because the "good" change was anterior.

> The above commit 396f46d904a was installed on master, AFAICT.

Yes.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Stefan Kangas]

Thierry Volpiatto <thievol@posteo.net> writes:

> No I was wrong, this commit has nothing to do with this, it is much more
> complex than this as the tags are on another line of development (AFAIU).
>
> Here what I find:
>
> Bad:
> ea5fd375bb2  Sat Mar 4 11:16:51 2023 Fix documentation of 'normal-mode' in buffers that don't v.. Eli Zaretskii
> (benchmark-run 1 (psession--dump-object-to-file-save-alist))
> (7.966819985 0 0.0)
>
> Good:
> 396f46d904a  Thu Feb 16 16:07:55 2023 bug#61489: Increase BLOCK_ALIGN from 1024 to 32768           Konstantin Kharlamov
> (benchmark-run 1 (psession--dump-object-to-file-save-alist))
> (0.488145912 0 0.0)

That's a pretty remarkable speedup, and shows that our work on improving
performance is paying off.

Re: Emacs-30 performances

[Mattias Engdegård]

9 juni 2024 kl. 08.41 skrev Thierry Volpiatto <thievol@posteo.net>:

> 396f46d904a  Thu Feb 16 16:07:55 2023 bug#61489: Increase BLOCK_ALIGN from 1024 to 32768

Did you verify this by applying that small change onto an emacs-29 tree (or reverting it from master)?

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 9 juni 2024 kl. 08.41 skrev Thierry Volpiatto <thievol@posteo.net>:
>
>> 396f46d904a  Thu Feb 16 16:07:55 2023 bug#61489: Increase BLOCK_ALIGN from 1024 to 32768
>
> Did you verify this by applying that small change onto an emacs-29 tree (or reverting it from master)?

Not yet, it took me a long time to find this (build, rebuild...), but
yes I will try and post here.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 578 bytes --]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 9 juni 2024 kl. 08.41 skrev Thierry Volpiatto <thievol@posteo.net>:
>
>> 396f46d904a  Thu Feb 16 16:07:55 2023 bug#61489: Increase BLOCK_ALIGN from 1024 to 32768
>
> Did you verify this by applying that small change onto an emacs-29 tree (or reverting it from master)?

Just verified by applying the patch on emacs-29 branch and no, this is
not the change that speedup emacs (so significantly at least), so I
don't know for now, if you have other suggestions to find this I take.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Mattias Engdegård]

10 juni 2024 kl. 07.32 skrev Thierry Volpiatto <thievol@posteo.net>:

> Just verified by applying the patch on emacs-29 branch and no, this is
> not the change that speedup emacs (so significantly at least), so I
> don't know for now, if you have other suggestions to find this I take.

The best you could do would be to reduce your setup to something that other people can run and reproduce the performance differences that you observed.

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 817 bytes --]

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> 10 juni 2024 kl. 07.32 skrev Thierry Volpiatto <thievol@posteo.net>:
>
>> Just verified by applying the patch on emacs-29 branch and no, this is
>> not the change that speedup emacs (so significantly at least), so I
>> don't know for now, if you have other suggestions to find this I take.
>
> The best you could do would be to reduce your setup to something that other people can run and reproduce the performance differences that you observed.

My setup is not involved here, you only have to install psession.el and
run (benchmark-run 1 (psession--dump-object-to-file-save-alist)) after
adding some variables to psession-object-to-save-alist.
Once done you delete ~/.emacs.d/elisp-objects directory and uninstall
psession.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Mattias Engdegård]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

15 juni 2024 kl. 07.32 skrev Thierry Volpiatto <thievol@posteo.net>:

> My setup is not involved here, you only have to install psession.el and
> run (benchmark-run 1 (psession--dump-object-to-file-save-alist)) after
> adding some variables to psession-object-to-save-alist.

Some variables? Which ones, exactly? And containing what?

To make progress we need a bit more precision. As a starting point I'm attaching the benchmark that I used but it's pure guesswork on my side. It shows a 1.3× speedup between Emacs 29.3 and master, which is nice but not quite your reported 16× improvement. This is with byte-compilation only, no native compilation.
Run it with

  emacs -Q -batch -f package-initialise -l psession-bench.elc

If you are unhappy with this benchmark, please propose an amendment that reproduces the effect you observed and that we can run, and which does not depend on your personal Emacs settings.


[-- Attachment #2: psession-bench.el --]
[-- Type: application/octet-stream, Size: 821 bytes --]

;;; -*- lexical-binding: t -*-

(require 'psession)

(defvar my-big-list
  (mapcar (lambda (n)
            (mapcar (lambda (m)
                      (let ((s (format "hello-%d-%d" m n)))
                        (list m n s (intern s))))
                    (number-sequence 1 100)))
            (number-sequence 1 1000)))

(push '(my-big-list . "my-big-list.el")
      psession-object-to-save-alist)

(defun bench ()
  (garbage-collect)
  (let* ((gcs0 gcs-done)
         (gc-elapsed0 gc-elapsed)
         (t0 (float-time))
         (_result (psession--dump-object-to-file-save-alist))
         (dt (- (float-time) t0))
         (gcs (- gcs-done gcs0))
         (gc-time (- gc-elapsed gc-elapsed0)))
    (message "%.3f s elapsed, %d GCs, %.3f s in GC, %.3f s non-GC"
             dt gcs gc-time (- dt gc-time))))

(bench)

[-- Attachment #3: Type: text/plain, Size: 2 bytes --]

Re: Emacs-30 performances

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]


Hello Mattias, sorry for late reply.

Mattias Engdegård <mattias.engdegard@gmail.com> writes:

> To make progress we need a bit more precision. As a starting point I'm
> attaching the benchmark that I used but it's pure guesswork on my
> side. It shows a 1.3× speedup between Emacs 29.3 and master,

Yes same here.

> which is nice but not quite your reported 16× improvement.

I think what make such a big difference is when saving hash-tables
instead of simple lists.

With:

(defvar my-big-list (make-hash-table :test 'equal))

(let ((i 0))
  (while (< i 10000)
    (puthash i (format "This is %d" i) my-big-list)
    (setq i (1+ i))))

(setq psession-object-to-save-alist '((my-big-list . "my-big-list.el")))

;; emacs-29: "0.758 s elapsed, 0 GCs, 0.000 s in GC, 0.758 s non-GC"
;; emacs-30: "0.016 s elapsed, 0 GCs, 0.000 s in GC, 0.016 s non-GC"


> This is with byte-compilation only, no native compilation.  Run it
> with
>
>   emacs -Q -batch -f package-initialise -l psession-bench.elc
                                       ^(z)

> If you are unhappy with this benchmark, please propose an amendment
> that reproduces the effect you observed and that we can run, and which
> does not depend on your personal Emacs settings.

I will try to come up with a version saving (larges) hash tables as soon as
possible.

Thanks.

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]

Re: Emacs-30 performances

[Mattias Engdegård]

21 juni 2024 kl. 07.25 skrev Thierry Volpiatto <thievol@posteo.net>:

> (defvar my-big-list (make-hash-table :test 'equal))
> 
> (let ((i 0))
>  (while (< i 10000)
>    (puthash i (format "This is %d" i) my-big-list)
>    (setq i (1+ i))))
> 
> (setq psession-object-to-save-alist '((my-big-list . "my-big-list.el")))
> 
> ;; emacs-29: "0.758 s elapsed, 0 GCs, 0.000 s in GC, 0.758 s non-GC"
> ;; emacs-30: "0.016 s elapsed, 0 GCs, 0.000 s in GC, 0.016 s non-GC"

Can't reproduce that; I get 0.020 and 0.019 s for emacs 29 and 30, respectively, on a slow machine.

It looks like your emacs-29 is configured, built or run differently.