Re: [Emacs-diffs] feature/byte-switch a75d080: * src/bytecode.c: Refactor to follow GNU coding standards

Re: [Emacs-diffs] feature/byte-switch a75d080: * src/bytecode.c: Refactor to follow GNU coding standards

[Stefan Monnier]

> +                    if (BYTE_CODE_SAFE)
> +                      eassert (!NILP (HASH_HASH (h, i)));

Declaring that non-full hashtables are "dangerous" is rather annoying.
In this case, I think we can do better:

                 Lisp_Object hash_code
                   = make_number (h->test.hashfn (&h->test, v1));

this then lets us use EQ (hash_code, ...) instead of hash_code == XUINT
(...)  which not only correctly skips nil hashes but might even be ever
so slightly faster (both use == on the same size of integers, but the
former avoids the cost of XUINT).


        Stefan

Re: [Emacs-diffs] feature/byte-switch a75d080: * src/bytecode.c: Refactor to follow GNU coding standards

[Vibhav Pant]

On Sat, Feb 11, 2017 at 9:16 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> +                    if (BYTE_CODE_SAFE)
>> +                      eassert (!NILP (HASH_HASH (h, i)));
>
> Declaring that non-full hashtables are "dangerous" is rather annoying.
> In this case, I think we can do better:
>
>                  Lisp_Object hash_code
>                    = make_number (h->test.hashfn (&h->test, v1));
>
> this then lets us use EQ (hash_code, ...) instead of hash_code == XUINT
> (...)  which not only correctly skips nil hashes but might even be ever
> so slightly faster (both use == on the same size of integers, but the
> former avoids the cost of XUINT).

Indeed. Since we only use hash_code when h->test.cmpfn is not NULL,
calculating it only then would also make sense (at the cost of an
extra NULL check).

-- 
Vibhav Pant
vibhavp@gmail.com