[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Time to merge scratch/correct-warning-pos into master, perhaps?
From: |
Eli Zaretskii |
Subject: |
Re: Time to merge scratch/correct-warning-pos into master, perhaps? |
Date: |
Sun, 16 Jan 2022 17:04:15 +0200 |
> Date: Sun, 16 Jan 2022 14:45:28 +0000
> Cc: larsi@gnus.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> > Are you saying that the measured slowdown is specific to the
> > byte-compiler, and will not affect other uses of Lisp, or affect them
> > much less heavily?
>
> Yes. The byte compile, as expected, is more slowed down than other
> software. On a quick measurement of compiling comp.el, I found a
> slowdown of around 12%
That seems to be inconsistent with the 17% slowdown compiling the *.el
files that Lars measured.
> > Because the byte-compiler is just another Lisp program, it doesn't in
> > general do anything an arbitrary Lisp program won't do.
>
> It does. It runs with symbols with position activated, so any operation
> involving an EQ which doesn't match is going to be significantly slower.
But EQ is not specific to the byte-compiler, is it?
> > Can you show a profile where this could be seen quantitatively?
>
> I'm not sure I understand. The slowdown in the byte compiler is
> distributed throughout the Emacs C Code. It doesn't happen at any
> particular isolated place.
I thought the slowdown was in Lisp somewhere. If it's in EQ, I'm not
sure I understand how come the byte-compiler's slowdown is so much
more significant than in other Lisp code.
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, (continued)
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Lars Ingebrigtsen, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Lars Ingebrigtsen, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?,
Eli Zaretskii <=
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Lars Ingebrigtsen, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Lars Ingebrigtsen, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/01/16
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Mattias EngdegÄrd, 2022/01/16