GNU bug report logs - #58338
29.0.50; mapatoms called on more elements than in obarray?

Previous Next

Package: emacs;

Reported by: Philip Kaludercic <philipk <at> posteo.net>

Date: Thu, 6 Oct 2022 16:17:02 UTC

Severity: normal

Found in version 29.0.50

Done: Philip Kaludercic <philipk <at> posteo.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: 58338 <at> debbugs.gnu.org
Cc: philipk <at> posteo.net
Subject: bug#58338: 29.0.50; mapatoms called on more elements than in obarray?
Date: Thu, 06 Oct 2022 22:35:17 +0300
Philip Kaludercic [2022-10-06 18:51 +0000] wrote:

> OK, then I'll close the report.  But if I am not supposed to use the
> obarrays, what would you recommend if I want to count the number of
> known symbols?  (Context:  I am trying to detect all variables defined
> in a package, and since that takes a while I wrapped the `mapatoms' call in
> a progress reporter, that needs a maximal value).

An obarray is just a flat vector of symbols, but each symbol itself
is actually implemented in C as a singly linked list of symbols (see
struct Lisp_Symbol).  If you inspect mapatoms you'll see it indeed
traverses each symbol chain in each vector bucket.

> What is even more vexing is that the deceptively named `obarray-size'
> just calls `length'.  Is there no better way to count the number of
> entries in a obarray, as `hash-table-count' does for hash tables?

Thus I don't think it's possible to know ahead of time the exact number
of symbols interned in a given obarray without traversing the whole
structure with mapatoms (but maybe I'm forgetting something obvious).

For this and associated reasons hash tables are generally preferred over
obarrays as an associative data structure, but for variables/symbols
we're stuck with obarray.

HTH,

-- 
Basil




This bug report was last modified 2 years and 226 days ago.

Previous Next


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