From: Alan Mackenzie <acm@muc.de>
To: Gregory Heytings <gregory@heytings.org>
Cc: larsi@gnus.org, mattiase@acm.org, Eli Zaretskii <eliz@gnu.org>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel@gnu.org
Subject: Re: Time to merge scratch/correct-warning-pos into master, perhaps?
Date: Fri, 4 Feb 2022 11:57:21 +0000 [thread overview]
Message-ID: <Yf0UoYGFzKNUnK1r@ACM> (raw)
In-Reply-To: <d472d15a1c5cbb4e4573@heytings.org>
Hello, Gregory.
On Fri, Feb 04, 2022 at 00:11:46 +0000, Gregory Heytings wrote:
> >>> More importantly, I wonder how slowing down EQ by a factor of 2 can
> >>> end up costing 10% of runtime when running the test suite. I think
> >>> this deserves investigation.
> >> Do you have an idea how this could be investigated?
> > Usually such slowdown don't come from everywhere at the same time. So
> > you need to "slice" our total time into subelements, and presumably some
> > of those elements show a higher slowdown, so you can focus on those and
> > start slicing them further.
> > As you get closer to the source, the slowdown should become more marked.
> You were too optimistic.
> I just finished a detailed analysis of the slowdown of the execution of
> Emacs' test suite, and it turns out that the slowdown is indeed spread
> over all tests.
> I attach the detailed results for each of the 389 tests. Each test has
> been executed 2000 (two thousand) times, again on an unloaded up-to-date
> Debian bookworm computer.
Just for completion's sake, that was presumably without native
compilation.
> If you look closer at the results, you will see that the slowdown is
> actually worse than 10%. The slowest of all tests (lisp/net/tramp-tests)
> is only 2% slower, because it uses external processes and is therefore not
> as much affected as other tests by the slowdown of bytecode execution
> itself. If you remove that test from the calculations, you will see that
> the slowdown is actually 17%, that is, the same slowdown as that of byte
> compilation.
> (FWIW, I was puzzled by the claim that byte compilation could be slowed
> down markedly, and that at the same time general bytecode execution would
> not. Byte compilation does not do anything that is fundamentally
> different from general bytecode execution.)
Compilation _does_ do things differently. It runs with
symbols-with-pos-enabled bound to t, which makes EQ slower than when
that variable is nil. To see this, have a look at the defition of
lisp_h_EQ in src/lisp.h, around line 372.
> My conclusion is that this merge should be backed out. Its performance
> impact has not been properly resolved and assessed.
These commits fixed a long standing bug, namely the outputting of wrong
position information in compiler warning messages. Perhaps you could
propose a better way of fixing that bug. For the record, I don't
believe there is a better way which is practical.
Also, there is something strange about the speed measurements on the
test suite that gives such marked slowdowns. On measurements of "real"
Emacs activities which don't involve compilation, the slowdowns measured
were "no measurable difference", 1% and 3%.
Perhaps you could hypothesize why there is such a large speed difference
in those tests, but not in real Emacs use. Such an understanding could
be useful. My guess is that there is an unusually large number of `eq's
in the test suite, and that it does very little garbage collection or
I/O.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2022-02-04 11:57 UTC|newest]
Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-15 18:15 Time to merge scratch/correct-warning-pos into master, perhaps? Alan Mackenzie
2022-01-15 18:24 ` Eli Zaretskii
2022-01-16 8:24 ` Lars Ingebrigtsen
2022-01-16 9:51 ` Po Lu
2022-01-16 13:50 ` Alan Mackenzie
2022-01-16 12:02 ` Lars Ingebrigtsen
2022-01-16 12:06 ` Po Lu
2022-01-16 13:12 ` Lars Ingebrigtsen
2022-01-16 14:02 ` Alan Mackenzie
2022-01-17 0:28 ` Po Lu
2022-01-17 3:28 ` Eli Zaretskii
2022-01-17 3:37 ` Po Lu
2022-01-16 14:00 ` Alan Mackenzie
2022-01-16 12:23 ` Eli Zaretskii
2022-01-16 12:26 ` Lars Ingebrigtsen
2022-01-16 12:36 ` Eli Zaretskii
2022-01-16 14:06 ` Alan Mackenzie
2022-01-16 14:11 ` Lars Ingebrigtsen
2022-01-16 14:21 ` Eli Zaretskii
2022-01-16 14:45 ` Alan Mackenzie
2022-01-16 15:04 ` Eli Zaretskii
2022-01-16 15:26 ` Alan Mackenzie
2022-01-16 15:43 ` Eli Zaretskii
2022-01-16 15:50 ` Alan Mackenzie
2022-01-16 13:47 ` Alan Mackenzie
2022-01-16 14:10 ` Lars Ingebrigtsen
2022-01-16 14:59 ` Stefan Monnier
2022-01-16 14:57 ` Stefan Monnier
2022-01-16 15:04 ` Lars Ingebrigtsen
2022-01-16 15:37 ` Alan Mackenzie
2022-01-16 15:50 ` Mattias Engdegård
2022-01-16 16:18 ` Alan Mackenzie
2022-01-16 16:52 ` Mattias Engdegård
2022-01-16 17:13 ` Stefan Monnier
2022-01-16 17:24 ` Mattias Engdegård
2022-01-22 12:23 ` Alan Mackenzie
2022-01-22 14:30 ` Lars Ingebrigtsen
2022-01-22 15:09 ` Alan Mackenzie
2022-01-22 15:26 ` Lars Ingebrigtsen
2022-01-22 15:36 ` Eli Zaretskii
2022-01-22 18:30 ` Alan Mackenzie
2022-01-23 12:45 ` Lars Ingebrigtsen
2022-01-22 16:06 ` Mattias Engdegård
2022-01-22 17:02 ` Gregory Heytings
2022-01-22 17:46 ` Eli Zaretskii
2022-01-22 18:01 ` Gregory Heytings
2022-01-22 18:12 ` Eli Zaretskii
2022-01-22 22:36 ` Gregory Heytings
2022-01-22 22:55 ` Alan Mackenzie
2022-01-23 6:16 ` Eli Zaretskii
2022-01-23 21:53 ` Gregory Heytings
2022-01-24 3:37 ` Eli Zaretskii
2022-01-24 15:20 ` Gregory Heytings
2022-01-24 16:47 ` Eli Zaretskii
2022-01-24 20:41 ` Gregory Heytings
2022-01-25 3:34 ` Eli Zaretskii
2022-01-25 8:59 ` Gregory Heytings
2022-01-25 11:27 ` Alan Mackenzie
2022-01-25 13:27 ` Stefan Monnier
2022-01-25 18:27 ` Alan Mackenzie
2022-01-25 19:26 ` Stefan Monnier
2022-01-25 20:58 ` Alan Mackenzie
2022-01-25 21:27 ` Gregory Heytings
2022-01-26 17:32 ` Alan Mackenzie
2022-01-26 18:59 ` Gregory Heytings
2022-01-26 20:26 ` Alan Mackenzie
2022-01-25 22:11 ` Stefan Monnier
2022-01-25 22:42 ` Óscar Fuentes
2022-01-26 1:08 ` Po Lu
2022-01-26 16:56 ` chad
2022-01-26 17:38 ` Eli Zaretskii
2022-01-26 17:58 ` chad
2022-01-26 18:46 ` Gregory Heytings
2022-01-26 19:47 ` Stefan Monnier
2022-01-26 19:59 ` Alan Mackenzie
2022-01-25 21:18 ` Gregory Heytings
2022-01-25 21:38 ` Gregory Heytings
2022-01-25 22:21 ` Stefan Monnier
2022-01-26 18:36 ` Gregory Heytings
2022-02-04 0:11 ` Gregory Heytings
2022-02-04 11:57 ` Alan Mackenzie [this message]
2022-02-04 12:06 ` Eli Zaretskii
2022-02-04 18:31 ` Alan Mackenzie
2022-02-04 18:54 ` Eli Zaretskii
2022-02-04 19:33 ` Alan Mackenzie
2022-02-04 19:46 ` Eli Zaretskii
2022-02-04 21:24 ` Alan Mackenzie
2022-02-04 22:24 ` Stefan Monnier
2022-02-04 22:30 ` Stefan Monnier
2022-02-05 7:28 ` Eli Zaretskii
2022-02-05 18:04 ` Stefan Monnier
2022-02-05 18:31 ` Eli Zaretskii
2022-02-05 8:17 ` Eli Zaretskii
2022-02-06 11:50 ` Alan Mackenzie
2022-02-06 11:56 ` Eli Zaretskii
2022-02-06 18:09 ` Alan Mackenzie
2022-02-06 18:39 ` Eli Zaretskii
2022-02-19 16:42 ` Alan Mackenzie
2022-02-19 17:02 ` Eli Zaretskii
2022-02-19 17:43 ` David Engster
2022-02-19 22:10 ` Alan Mackenzie
2022-02-20 5:35 ` David Engster
2022-02-20 19:45 ` Alan Mackenzie
2022-02-20 20:37 ` Stefan Monnier
2022-02-20 20:56 ` Alan Mackenzie
2022-02-20 23:02 ` Stefan Monnier
2022-02-21 0:22 ` Óscar Fuentes
2022-02-21 3:31 ` Eli Zaretskii
2022-02-21 4:04 ` Óscar Fuentes
2022-02-21 12:15 ` Eli Zaretskii
2022-02-21 14:55 ` Óscar Fuentes
2022-02-21 3:29 ` Eli Zaretskii
2022-02-19 19:01 ` Stefan Monnier
2022-02-19 19:30 ` Eli Zaretskii
2022-02-19 22:03 ` Alan Mackenzie
2022-02-25 22:29 ` Alan Mackenzie
2022-02-06 18:40 ` Eli Zaretskii
2022-02-06 19:03 ` Eli Zaretskii
2022-02-07 17:36 ` Andrea Corallo
2022-02-05 6:08 ` Lars Ingebrigtsen
2022-02-05 11:42 ` Alan Mackenzie
2022-02-05 21:31 ` Lars Ingebrigtsen
2022-02-06 7:02 ` Eli Zaretskii
2022-02-06 11:38 ` Alan Mackenzie
2022-02-06 23:14 ` Lars Ingebrigtsen
2022-01-25 21:15 ` Gregory Heytings
2022-01-25 21:30 ` Andrea Corallo
2022-01-26 18:43 ` Gregory Heytings
2022-01-26 21:04 ` Andrea Corallo
[not found] ` <b0265c41-7ead-4913-667-d0e76a35b3ba@heytings.org>
2022-01-25 21:16 ` Gregory Heytings
2022-01-25 12:26 ` Eli Zaretskii
2022-01-26 18:41 ` Gregory Heytings
2022-01-26 18:59 ` Eli Zaretskii
2022-01-26 19:14 ` Stefan Monnier
2022-01-26 19:32 ` Eli Zaretskii
2022-01-26 19:34 ` Alan Mackenzie
2022-01-22 18:35 ` Alan Mackenzie
2022-01-22 18:45 ` Gregory Heytings
2022-01-22 18:50 ` Eli Zaretskii
2022-01-22 20:07 ` Gregory Heytings
2022-01-23 5:32 ` Eli Zaretskii
2022-01-23 21:44 ` Gregory Heytings
2022-01-15 22:57 ` Stefan Monnier
2022-01-16 0:27 ` Brahimi Saifullah
2022-01-16 14:53 ` Alan Mackenzie
2022-01-16 16:45 ` Brahimi Saifullah
2022-01-22 11:41 ` Alan Mackenzie
2022-01-22 23:16 ` Brahimi Saifullah
2022-01-23 14:09 ` Alan Mackenzie
2022-01-17 9:38 ` Andrea Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Yf0UoYGFzKNUnK1r@ACM \
--to=acm@muc.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=gregory@heytings.org \
--cc=larsi@gnus.org \
--cc=mattiase@acm.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.