From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: ghe@sdf.org, larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Redisplay slower in Emacs 28 than Emacs 27
Date: Thu, 10 Dec 2020 11:21:42 -0500 [thread overview]
Message-ID: <jwvpn3hwtg0.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83v9da49it.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Dec 2020 05:36:42 +0200")
>> > 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
next prev parent reply other threads:[~2020-12-10 16:21 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-07 14:53 Redisplay slower in Emacs 28 than Emacs 27 Gregory Heytings via Emacs development discussions.
2020-12-07 15:04 ` Lars Ingebrigtsen
2020-12-07 15:14 ` Gregory Heytings via Emacs development discussions.
2020-12-07 15:19 ` Lars Ingebrigtsen
2020-12-07 15:28 ` Gregory Heytings via Emacs development discussions.
2020-12-07 15:41 ` Lars Ingebrigtsen
2020-12-07 15:43 ` Gregory Heytings via Emacs development discussions.
2020-12-07 15:45 ` Gregory Heytings via Emacs development discussions.
2020-12-07 16:14 ` Lars Ingebrigtsen
2020-12-07 16:46 ` Gregory Heytings via Emacs development discussions.
2020-12-07 17:30 ` Eli Zaretskii
2020-12-07 18:45 ` Gregory Heytings via Emacs development discussions.
2020-12-07 18:47 ` Lars Ingebrigtsen
2020-12-07 18:49 ` Gregory Heytings via Emacs development discussions.
2020-12-07 20:58 ` Alan Third
2020-12-07 21:24 ` Gregory Heytings via Emacs development discussions.
2020-12-07 21:06 ` Gregory Heytings via Emacs development discussions.
2020-12-07 21:15 ` Lars Ingebrigtsen
2020-12-07 21:23 ` Alan Third
2020-12-07 21:31 ` Lars Ingebrigtsen
2020-12-07 21:47 ` Lars Ingebrigtsen
2020-12-07 21:46 ` Gregory Heytings via Emacs development discussions.
2020-12-07 21:49 ` Gregory Heytings via Emacs development discussions.
2020-12-07 21:59 ` Lars Ingebrigtsen
2020-12-07 22:11 ` Lars Ingebrigtsen
2020-12-07 22:56 ` Gregory Heytings via Emacs development discussions.
2020-12-07 23:02 ` Lars Ingebrigtsen
2020-12-07 23:09 ` Gregory Heytings via Emacs development discussions.
2020-12-07 23:44 ` Lars Ingebrigtsen
2020-12-07 23:47 ` Lars Ingebrigtsen
2020-12-08 0:04 ` Gregory Heytings via Emacs development discussions.
2020-12-07 23:48 ` Lars Ingebrigtsen
2020-12-08 0:17 ` Gregory Heytings via Emacs development discussions.
2020-12-08 0:23 ` Lars Ingebrigtsen
2020-12-08 0:41 ` Lars Ingebrigtsen
2020-12-08 1:21 ` Lars Ingebrigtsen
2020-12-08 17:21 ` João Távora
2020-12-08 14:58 ` Eli Zaretskii
2020-12-08 15:07 ` Lars Ingebrigtsen
2020-12-08 15:19 ` Lars Ingebrigtsen
2020-12-08 16:17 ` Eli Zaretskii
2020-12-08 16:34 ` Lars Ingebrigtsen
2020-12-08 16:56 ` Eli Zaretskii
2020-12-08 17:52 ` Lars Ingebrigtsen
2020-12-08 16:11 ` Eli Zaretskii
2020-12-07 22:23 ` Alan Third
2020-12-07 22:32 ` Lars Ingebrigtsen
2020-12-07 18:50 ` Lars Ingebrigtsen
2020-12-07 19:26 ` Eli Zaretskii
2020-12-08 14:06 ` Lars Ingebrigtsen
2020-12-08 15:50 ` Eli Zaretskii
2020-12-08 15:56 ` Stefan Monnier
2020-12-08 16:21 ` Eli Zaretskii
2020-12-08 16:31 ` Lars Ingebrigtsen
2020-12-08 16:53 ` Eli Zaretskii
2020-12-08 17:29 ` Lars Ingebrigtsen
2020-12-08 17:36 ` Eli Zaretskii
2020-12-08 17:51 ` Lars Ingebrigtsen
2020-12-08 18:03 ` Eli Zaretskii
2020-12-08 18:39 ` Stefan Monnier
2020-12-08 19:12 ` Lars Ingebrigtsen
2020-12-08 19:36 ` Lars Ingebrigtsen
2020-12-08 20:21 ` Eli Zaretskii
2020-12-08 20:32 ` Lars Ingebrigtsen
2020-12-08 20:35 ` Lars Ingebrigtsen
2020-12-08 20:51 ` Lars Ingebrigtsen
2020-12-08 21:10 ` Alfred M. Szmidt
2020-12-08 21:41 ` Lars Ingebrigtsen
2020-12-08 22:31 ` Alfred M. Szmidt
2020-12-08 21:33 ` Stefan Monnier
2020-12-08 22:46 ` Stefan Monnier
2020-12-08 22:58 ` Lars Ingebrigtsen
2020-12-08 23:10 ` Stefan Monnier
2020-12-08 23:43 ` Lars Ingebrigtsen
2020-12-09 18:49 ` Eli Zaretskii
2020-12-09 21:01 ` Stefan Monnier
2020-12-10 3:36 ` Eli Zaretskii
2020-12-10 16:21 ` Stefan Monnier [this message]
2020-12-07 16:06 ` Óscar Fuentes
2020-12-07 16:15 ` Gregory Heytings via Emacs development discussions.
2020-12-07 16:16 ` Eli Zaretskii
2020-12-07 15:21 ` Jean Louis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvpn3hwtg0.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ghe@sdf.org \
--cc=larsi@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).