From: Paul Eggert <eggert@cs.ucla.edu>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: 32405@debbugs.gnu.org
Subject: bug#32405: Turning misc objects into pseudovectors
Date: Wed, 8 Aug 2018 22:01:09 -0700 [thread overview]
Message-ID: <89c3c3be-4c08-32c7-7ecf-8bae1aa78305@cs.ucla.edu> (raw)
In-Reply-To: <20180809025852.28874-1-eggert@cs.ucla.edu>
> 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.
To some extent the point of this change is that we don't need a separate
Lisp_Object tag in order to have size-segregated allocation, since pseudovectors
already do that.
> Are you sure the new code is faster overall?
That's what I measured with 'make compile-always', yes. Of course this is just
one benchmark. (My original intuition was that nobody would notice the
difference....)
> 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).
next prev parent reply other threads:[~2018-08-09 5:01 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 ` Paul Eggert [this message]
2018-08-09 7:16 ` bug#32405: Turning " Paul Eggert
2018-08-09 16:24 ` Stefan Monnier
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=89c3c3be-4c08-32c7-7ecf-8bae1aa78305@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=32405@debbugs.gnu.org \
--cc=monnier@IRO.UMontreal.CA \
/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).