[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: Tue, 27 Nov 2018 18:18:49 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

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.

reply via email to

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