[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: Alan Mackenzie
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Sat, 1 Dec 2018 12:47:27 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Martin.

On Sat, Dec 01, 2018 at 08:35:54 +0100, martin rudalics wrote:
>  > All in all the status quo is preferable to
>  > scratch/accurate-warning-pos. Although I don't expect you to agree
>  > with me on this, I don't think I'm alone in having concerns about
>  > the significant performance issues here.

> There are around 50 issues in current Emacs that annoy me at least as
> much as wrong positions reported by the byte compiler.

Likely, none of them are as difficult to address as the byte compiler
bug.  But who's going to address them, if they can expect the reaction
I'm getting at the moment?

> If, on the average, solving any such issue took away just 2% of the
> performance of my Emacs, I'd experience an overall slowdown of 100%
> when solving all of them.  So please note that Paul is not alone with
> his concerns.

On average, solving these other bugs will cost 0% in performance.
You're positing a completely unrealistic scenario.

Have you even tried scratch/accurate-warning-pos?  You've said in the
past that you have a slow machine, so if that's still true, you would
probably be the person to notice perceptible slowdown, should there be
any.  Do you notice any slowdown with it?

The byte compiler bug is extremely unusual, possibly unique, in its
resistance to being resolved.  Just about every possible approach has
been tried (along with several which are not possible), and only one
approach, the one in scratch/accurate-warning-pos, has got anywhere at

If you still object to this fix, even after trying it, what you are
saying is that you prefer fast buggy software over slightly slower
functional software.

> martin

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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