Re: The poor quality of Emacs's backtraces

[Mattias Engdegård]

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.)

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.

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.

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.

But more importantly, since you said yourself that you would have been 
satisfied with a backtrace that included the faulting operation, 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.