Re: The poor quality of Emacs's backtraces

[Alan Mackenzie]

Hello, Mattias.

On Mon, Jul 17, 2023 at 17:52:12 +0200, Mattias Engdegård wrote:
> 14 juli 2023 kl. 22.51 skrev Alan Mackenzie <acm@muc.de>:

> > Aren't we always careful?  I wasn't intending to make anything slower
> > (except, marginally, the handling of errors).

> Your intent is not in doubt, but the execution path is so sensitive
> that seemingly minor changes often have outsized effect on performance.
> (This cuts both ways: there have also been optimisation opportunities
> in what appeared to be reasonably efficient code.)

Well, I've committed the code (see below).  Please actually measure it
and point out where it is actually slow, rather than pontificating on
vague abstractions.

> Bug#64613 has been opened for this effort, and I intend to continue it
> shortly. I'm certainly open for ideas about how to solve the problem
> efficiently and effectively.

> > I have working code implementing the putting of this extra
> > information into backtraces.

> Writing code is the easy part. What I'm wary about is rushing a
> solution -- your solution -- to a problem that hasn't yet been studied
> in sufficient depth, and with no regard to the costs involved: not just
> performance but also the fact that other people, myself included, will
> be the ones to maintain the feature for all foreseeable future.

Well, that's one way of ensuring nothing will ever get done.

I pushed this working code this morning to the new branch
feature/named-lambdas, precisely to give people something concrete to
study, to criticize, to measure, to improve upon, and possibly to reject.

If you're going to reject anything, please reject the code, with good
reason, not vague abstract ideas.

And please don't exaggerate the "ease" with which it was written.

> The problem is compounded by our current suboptimal representation of
> closures: instead of the typical ⟨function, environment⟩ tuple, we
> represent them as copies of the function object with closed-over
> variables allocated separately and hacked into the (also copied)
> constant vector. Making that copied function object even bigger is the
> opposite of what we want to do.

I don't agree, at least not at the moment.  The function object, all
three varieties, is big enough to hold all the information it needs to
hold.  Should it need to become marginally bigger, so be it.

> There is also the question of what information should be there if any
> were to be added. For example, source location could arguably be more
> useful than function name.

These are all things that can be changed later.  The main danger is doing
nothing but talk, talk, talk, ....  Then the topic will die down, and
come up again weeks, months in the future, possibly in a bug report, when
we will talk, talk, talk, again.  There is a cost to not fixing things.

> But more importantly, since you said yourself that you would have been
> satisfied with a backtrace that included the faulting operation, ....

I think you've misunderstood me.  That "faulting operation" is merely one
of the things I want.  I would not be satisfied by just that.  The
identity of the code referred to by each backtrace line is also
essential.

> .... and we agree that this is something we want in any case, wouldn't
> it make sense to begin there? The risk is much lower and it won't
> saddle us with irreversible maintenance costs.

Whatever we do will involve "maintenance costs".  Having coded this
change, I have some good idea of where undue maintenance costs in the
Lisp engine lie.  I don't think they're where you might think.

-- 
Alan Mackenzie (Nuremberg, Germany).