Re: Redisplay slower in Emacs 28 than Emacs 27

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> > Btw, any particular reason for the cutoff of 16 bytes to switch to the
>> > "large chunk" branch?
>> The reason is that I felt it looked good ;-)
>> Well, not only: the "large chunk" branch operates 8bytes at a time on
>> 64bit systems, so if we use it on a 15B string it will only consult the
>> first 8B which I thought wasn't good enough, whereas I felt that
>> ignoring the last 7B of a 23B string was acceptable.
> Then perhaps we should look for the optimal cutoff by benchmarking
> with different values?

If someone feels like it, I won't get in the way.  Personally, I don't
think "optimal" is needed here.

BTW, we could also get rid of the "old, slow code" and instead improve
the fast code so it doesn't throw away the last <8 bytes.  If done
right, it would likely also speed up the case of strings shorter than
16 bytes.

If we presume that `p` itself is naturally aligned (which I believe
should indeed always be the case), then we can safely use a word-sized
read at the end (it will read some trailing garbage bytes, but won't
risk hitting a memory protection check) and then "mask out" those
trailing bytes.  But that masking requires endian-dependent code, so
I refrained from going down that road.  I guess if we could arrange for
those trailing bytes to always be the same (e.g. always NUL), then we
wouldn't even need to do that masking, but AFAIK while we do make sure
there's always a trailing NUL right after the end of our strings, we
don't ensure that there are trailing NULs right up to the next multiple
of 4-or-8 address.

Admittedly, big-endians lost the war and are a disappearing breed
nowadays, but they still haven't quite disappeared, sadly [ I was
rooting for the big-endians, but given where we're at, I'd rather see
big-endians be a thing of the past.  ]


        Stefan