|
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.
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.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.
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.
[Prev in Thread] | Current Thread | [Next in Thread] |