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

[Paul Eggert]

On 11/27/18 2:09 PM, Stefan Monnier wrote:
> > Hash tables for cons locations would work well enough, if someone had the
> > time to put into it.
> Experiment with this approach seemed to indicate that it would slowdown
> compilation tremendously (not just a few percents) because of the cost
> of all those hash table operations.

That's too bad. Why is hashing so slow? Can we speed it up?

Another possibility is to have a special hashing mechanism just for 
pairs that are allocated to be hashable. This would work by having a 
special alternative to struct cons_block for which it would be trivial 
to convert the address of a hashable pair to the address of the 
corresponding value (simply add a constant to the address, say). The new 
'read' function could return hashable pairs. A hashable pair would have 
the same structure as an ordinary pair so all existing functions 
(including C macros) would work with it. This should be fast enough.


> So I was thinking of reducing the pain by re-using the edebug info so as
> to find those arguments (or parts of arguments) which are treated as
> normal expressions, which we don't need to de-annotate.
Hmm, I know little about edebug so I'm afraid this suggestion is mostly 
Greek to me.