Re: Redisplay slower in Emacs 28 than Emacs 27

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> That is, use
>> 
>>      && EQ (img->spec, spec)
>> 
>> instead of
>> 
>>      && equal_lists (img->spec, spec)
>
> I think using EQ might break something, given that we've been using
> Fequal for a long time.

Yeah, the equal_lists thing did break the toolbar cache, so there might
be other breakages.  On the other hand, it seems like it didn't break
much else, so we might want to continue in this direction to make
redisplay of images faster.

And moving to just EQ is one more step in that direction.

>> Or, if we decide to revert to a more permissive cache again, we could
>> just go back to using
>> 
>>      && !NILP (Fequal (img->spec, spec))
>
> We could do that, yeah.  But most of the members of an image spec are
> symbols and suchlikes, so maybe we could use EQ for almost all of
> them, except for strings?

Fequal is already pretty optimised, so in practice, it isn't that
different, really.  Its uses EQ for symbols and stuff, and I think it
compares strings with EQ first, and only looks at the contents of the
strings if they aren't EQ?  Or do I misremember?

So moving to Fequal is fine if we decide to have the Emacs 27 caching
semantics.

However, if we move to EQ semantics, the real speedup is that we don't
have to call sxhash(img) on all the images -- and that's a slow
operation, because it'll call hash_string on all the string contents,
and if you have a large :data image, it'll compute that every time Emacs
decides to redisplay that image.

My proposal is: Be explicit in documenting how images are cached, and
only cache images based on EQ-ness of the spec.  That will speed up
redisplay of large :data images substantially (since we never need to do
an sxhash on the spec).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no