From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 32405@debbugs.gnu.org
Subject: bug#32405: Turning misc objects into pseudovectors
Date: Thu, 09 Aug 2018 12:24:48 -0400 [thread overview]
Message-ID: <jwvy3df8qj8.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <89c3c3be-4c08-32c7-7ecf-8bae1aa78305@cs.ucla.edu> (Paul Eggert's message of "Wed, 8 Aug 2018 22:01:09 -0700")
>> AFAIK the main issue with pseudovectors is that their allocation is
>> slower and suffers more from fragmentation (because we don't use
>> a size-segregated allocation algorithm (like Linux's SLAB, for example)
>> for them).
>
> Pseudovectors do have size-segregated allocation; see the vector_free_lists
> array. Although it's not as fancy as Linux's SLAB, I hope it's enough for
> Emacs; if not we could of course make it fancier.
Ah, I had forgotten about vector_free_lists. So I guess it will likely
suffer a bit more from fragmentation, but performance should be
good enough, thanks.
>> Are you sure the new code is faster overall?
> That's what I measured with 'make compile-always', yes.
Cool!
> Of course this is just one benchmark. (My original intuition was that
> nobody would notice the difference....)
I think you're right.
>> There is also a potential issue in terms of the resulting heap size of
>> markers (which may bump up from 6 words to 8 words, IIRC, unless your
>> patch does something to keep it down to 6)
> On a 64-bit platform the heap size of markers does not grow. The old size is
> 6 words (sizeof (union aligned_Lisp_Misc) is 48), and the new size is also
> 6 words (sizeof (struct Lisp_Marker) is also 48).
Perfect, thanks,
Stefan
next prev parent reply other threads:[~2018-08-09 16:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-09 2:58 bug#32405: [PATCH] Turn misc objects into pseudovectors Paul Eggert
2018-08-09 5:01 ` bug#32405: Turning " Paul Eggert
2018-08-09 7:16 ` Paul Eggert
2018-08-09 16:24 ` Stefan Monnier [this message]
2018-08-09 6:11 ` bug#32405: [PATCH] Turn " Pip Cet
2018-08-09 7:44 ` Paul Eggert
2018-08-10 2:01 ` Richard Stallman
2018-08-09 17:23 ` Andy Moreton
2018-08-09 17:53 ` Pip Cet
2018-08-09 18:10 ` Paul Eggert
2018-08-09 18:24 ` Paul Eggert
[not found] <988905f1-fb41-9559-300d-d015bda4b791@cs.ucla.edu>
2018-08-09 3:58 ` bug#32405: Turning " Stefan Monnier
2018-08-09 16:31 ` Tom Tromey
[not found] ` <8736vn8pso.fsf@tromey.com>
2018-08-09 17:22 ` Paul Eggert
2018-08-09 18:27 ` Eli Zaretskii
[not found] ` <83o9ebo0or.fsf@gnu.org>
2018-08-10 13:43 ` Tom Tromey
[not found] ` <87o9ea5od7.fsf@tromey.com>
2018-08-12 1:53 ` Paul Eggert
[not found] ` <ce9022a7-c1cf-4969-d769-2d2c33a1f2af@cs.ucla.edu>
2018-08-14 19:11 ` Paul Eggert
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=jwvy3df8qj8.fsf-monnier+emacsbugs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=32405@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
/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).