Re: Bug#38708: eq vs eql in byte-compiled code

[Pip Cet]

On Thu, Jan 2, 2020 at 7:52 AM Paul Eggert <address@hidden> wrote:
> I did that, and surprise! it sped up 'make compile-always' by about 7% on the
> two platforms I tried it on (Fedora 31 and Ubuntu 18.04.3, both x86-64).

For what it's worth, I'm not seeing that effect, and it seems too
large to me to be easily explicable.

I might be mistaken, but our hash tables never shrink, do they? That
sounds like a potential problem to me, particularly for people who
mess about with gc settings; but I haven't been able to produce a
problem in practice with your patch.

> Two or three issues:
>
> * Should we document that eq == eql on bignums, or continue to leave this 
> stuff
> unspecified?

I don't think we should be making any new promises about eq.

> * Should we try hash-consing floats too? Maybe it wouldn't be as slow as we
> thought, for typical computations anyway....

I think the answer is yes here...

> * The attached patch could probably be sped up a bit by supporting sets as 
> well
> as mappings at the low level, since bignum_map is really just a set of 
> bignums.
> Not sure it's worth the effort, though.

if it's also yes here.