GNU bug report logs - #78620
[PATCH] Make obarray's buckets a Lisp_Vector

Previous Next

Package: emacs;

Reported by: Helmut Eller <eller.helmut <at> gmail.com>

Date: Wed, 28 May 2025 12:05:04 UTC

Severity: normal

Tags: notabug, patch, wontfix

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 78620 <at> debbugs.gnu.org (full text, mbox):

From: Mattias EngdegÄrd <mattias.engdegard <at> gmail.com>
To: 78620 <at> debbugs.gnu.org
Cc: Pip Cet <pipcet <at> protonmail.com>, Helmut Eller <eller.helmut <at> gmail.com>
Subject: bug#78620: [PATCH] Make obarray's buckets a Lisp_Vector
Date: Thu, 29 May 2025 17:02:17 +0200
(I just saw this bug by chance -- if you want my comments on code I wrote, CC: me explicitly)

Thank you for caring about the obarray internals. The reason why the obarray and hash-table implementations don't use Lisp allocations for their tables is that with the current GC, it's much more efficient to allocate and free them explicitly to handle growth.

MPS may alter the balance but the concern remains real: eager freeing of memory immediately when it becomes dead is inherently more memory-efficient than waiting for it to be collected, and since the freed memory can be taken into use at once it improves locality.

This is the reason why it's written that way, and plenty of measurements were made at the time. There may still be good arguments for changing the structure but be careful, and don't do it for aesthetics alone.

(And no, I'm not very happy with the internal obarray representation which was basically kept unchanged when the new obarray objects were added. Especially the way symbols in each bucket are chained together with ->next pointers, that's a bit unfortunate. But it works, and is a lot faster than it was before.)





This bug report was last modified 53 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.