Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.

[Alan Mackenzie]

Hello, Paul.

On Mon, Nov 26, 2018 at 18:48:49 -0800, Paul Eggert wrote:
> On 11/26/18 10:43 AM, Alan Mackenzie wrote:
> > read the thread "Thoughts on getting correct line
> > numbers in the byte compiler's warning messages", which began here on
> > 2018-11-01.

> I read that thread, but to be honest my eyes began glazing over. I'm 
> sure I missed some points.

:-)  Yes, I get that too, sometimes.

Perhaps the main conclusion we came to was that it is far better working
with symbols than with conses.  Even after macro-expansion, and
processing by byte-opt.el and cconv.el, the symbols persist.  Mostly.
The cons cells don't, not at all.

Creating the double Lisp interpreter is orthogonal to this choice
between symbols and conses.  i would recommend you to use the mechanism
in scratch/accurate-warning-pos in your new version.  It works, and all
you have to do is get over your distaste for EQ ignoring source
positions when comparing symbols.

> > The slowdown seems to be chrystallising out at 20 - 25% while byte
> > compiling, and 5 - 20% otherwise.
> >
> > This may be significant, but is it really important?  Most of the time,
> > Emacs is waiting for the next key depression anyway.

> And most of the time, my office at work is empty. That doesn't mean I 
> don't care how well my office performs when a half-dozen people squeeze 
> into it and try to get work done (which happened multiple times 
> today...). Emacs regularly reacts too slowly for me when I use it in 
> ordinary interaction, and I'd rather not see it get significantly slower.

OK, that's a valid statement.

> > As a data point, my 1.5 year old machine is about 150% faster (per core)
> > than its predecessor.
> My desktop uses a circa 2010 design and is no doubt significantly slower 
> than your machine. No doubt that partly explains why I'm more sensitive 
> about performance issues.

Not really.  My previous machine was from 2009, and I don't recall
problems with sluggishness.  Possibly slowness in batch-like operations,
yes, but not sluggishness.  Maybe your brain just works faster than mine
does.

Emacs used to work OK on machines 10, 100 times slower than what we have
today.  Were there really that many complaints about its speed?

-- 
Alan Mackenzie (Nuremberg, Germany).