unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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).





  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).