[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 19:33:28 +0000 |
Hello, Eli.
On Fri, Feb 04, 2022 at 20:54:20 +0200, Eli Zaretskii wrote:
> > Date: Fri, 4 Feb 2022 18:31:01 +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>
> > > 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.
> I don't see how the number of combinations is relevant. If all you
> need to compare is the symbol part, then whether there's something
> after it in memory is not interesting and doesn't affect comparison.
Yes, that's true.
> > Specific questions:
> > > . comparison of a symbol and symbol-with-pos should only compare the
> > > symbol part, and disregard the "pos" part, right?
Yes.
> > > . 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.
> Sorry, I don't understand how this answers my questions.
OK, I don't think we can improve the performance by the use of a struct
containing the symbol followed by the position. I'm not sure what more I
can add.
> > Don't forget that the position attaches to the symbol OCCURRENCE,
> > not the symbol itself.
> I don't understand what I need not to forget, please elaborate.
In the moderate past, that thing, the (lack of) possibility of attaching
the position to the symbol, caused me a lack of clarity. I forgot many
times that we need to deal with symbol occurrences, not symbols.
We cannot extend struct Lisp_Symbol with the position, since a single
symbol typically occurs several times in different positions. Rather, I
think we would need to extend the Lisp_Object in this fashion.
> What is there in a symbol-with-pos except the symbol and the position?
There is the symbol, the position, and a pseudovector header.
> (And please be more cooperative and forthcoming, since my questions
> are meant to help make this feature less expensive, otherwise there's
> a real chance of the feature to be removed, something I hope you don't
> want.)
Sorry, I was doing my best to answer what I thought you were asking. I
wasn't trying to be evasive.
--
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, 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?, 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, 2022/02/06
- Re: Time to merge scratch/correct-warning-pos into master, perhaps?, Eli Zaretskii, 2022/02/06