[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Time to merge scratch/correct-warning-pos into master, perhaps?
From: |
Alan Mackenzie |
Subject: |
Re: Time to merge scratch/correct-warning-pos into master, perhaps? |
Date: |
Sun, 6 Feb 2022 11:50:02 +0000 |
Hello, Eli.
On Sat, Feb 05, 2022 at 10:17:36 +0200, Eli Zaretskii wrote:
> > Date: Fri, 4 Feb 2022 21:24:56 +0000
> > Cc: gregory@heytings.org, monnier@iro.umontreal.ca, mattiase@acm.org,
> > larsi@gnus.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > > First, are symbols-with-pos supposed to happen in bytecode that
> > > doesn't deal with byte compilation?
> > Symbols with pos are intended to be used only in compilation, native- as
> > well as byte-. They mustn't be output to .elc files.
> So that would mean the slowdown of EQ is due to the cases where the
> objects are not-EQ?
Yes.
> Where are the numbers that show how much slower is the current EQ, for
> the case of EQ and not-EQ objects?
We don't have any such numbers. Is it even possible to measure this? On
earlier processors, we could have just counted up processor cycles used
for each instruction, but not any more.
> > > If yes, why/when would such objects appear in GP bytecode?
> > What does "GP" mean here, please?
> General Purpose.
Thanks. Symbols with position shouldn't appear at all in general purpose
bytecode.
> > > > > What is there in a symbol-with-pos except the symbol and the position?
> > > > There is the symbol, the position, and a pseudovector header.
> > > The pseudovector part is not needed if we just extend Lisp_Symbol to
> > > have an additional field 'position'.
> > Yes. I'm not sure we can do this, though.
> Let's revisit that once we understand the slowdown of EQ better and
> more quantitatively.
OK.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, (continued)
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/04
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/04
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/04
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/04
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/02/04
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/02/04
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/05
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/02/05
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/05
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/05
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?,
Alan Mackenzie <=
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/06
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/06
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/06
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, David Engster, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/19
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, David Engster, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Alan Mackenzie, 2022/02/20
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Stefan Monnier, 2022/02/20