[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Fri, 30 Nov 2018 12:14:59 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 11/30/18 10:55 AM, Alan Mackenzie wrote:
There are no performance "issues".  Emacs with this bug fix is minutely
slower than without it, not enough to matter.

I'm afraid we'll have to disagree about that. It's not worth slowing all Emacs computations by 3.5% - 10% or whatever, merely to get more-accurate locations in byte-compiler diagnostics. That is a significant slowdown, and it's too much of a price to pay for such a small benefit.

I too have played with the idea to redefine eq, for a different purpose (so that bignums behave more like fixnums), and I gave it up because of similar slowdowns. It wasn't worth the cost there either. Sometimes ideas just don't work out.

The point of the exercise is specific, not vague as you have
misformulated it.  It is to print the correct source locations in
compiler warnings which are currently being output as wrong locations.
For example, read bug #9109.
Bug #9109 could be fixed by a read variant that returns symbols-with-positions, by changing the byte-compiler to understand the output of this read variant, and by having the byte compiler remove position information before passing a subexpression to a macro. It could also be fixed by a read variant that returns conses-with-positions. Neither fix would slow down ordinary code. However, as I understand it, we don't want either fix because these fixes would still generate subpar locations in diagnostics when byte-compiling other code that calls macros. This is why I have been thinking about other code errors that involve macros, errors that you say are out of scope.

When trying to consider alternatives to scratch/accurate-warning-pos, I was trying to get an understanding of problem scope that is independent of the proposed solution. Unfortunately I failed to do that, and this makes it difficult to consider alternatives.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]