[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: |
Fri, 4 Feb 2022 18:31:01 +0000 |
Hello, Eli.
On Fri, Feb 04, 2022 at 14:06:39 +0200, Eli Zaretskii wrote:
> > Date: Fri, 4 Feb 2022 11:57:21 +0000
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, mattiase@acm.org,
> > Eli Zaretskii <eliz@gnu.org>, larsi@gnus.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > 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.
> Can you explain why we need to complicate EQ so much to account for
> symbols-with-pos?
There are four possible ways the two Lisp objects might match - each
object can be either a bare symbol, or a symbol with pos, giving four
possibilities. It's worth noting that the last three possibilities are
cut off completely by the check on symbols-with-pos-enabled, except
during compilation.
Specific questions:
> . comparison of a symbol and symbol-with-pos should only compare the
> symbol part, and disregard the "pos" part, right?
> . if so, couldn't we implement symbol-with-pos as a struct that has
> the symbol at its beginning, and then use memcmp to compare only
> that part?
> Or what am I missing?
I don't think we can get anywhere that way. What gets compared in EQ
are the Lisp_Object's, which are typically already in processor
registers. I don't think we typically have a pointer to memory
containing the symbol with position. Don't forget that the position
attaches to the symbol OCCURRENCE, not the symbol itself.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Gregory Heytings, 2022/02/03
- 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 <=
- 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