all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Basil L. Contovounesios" via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: 58338@debbugs.gnu.org
Cc: philipk@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	[thread overview]
Message-ID: <87h70gu4ne.fsf@tcd.ie> (raw)
In-Reply-To: <87mta8lr9c.fsf@posteo.net> (Philip Kaludercic's message of "Thu,  06 Oct 2022 18:51:43 +0000")

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





  reply	other threads:[~2022-10-06 19:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-06 16:16 bug#58338: 29.0.50; mapatoms called on more elements than in obarray? Philip Kaludercic
2022-10-06 17:55 ` Gerd Möllmann
2022-10-06 18:21   ` Philip Kaludercic
2022-10-06 18:25     ` Gerd Möllmann
2022-10-06 18:28       ` Philip Kaludercic
2022-10-06 18:32         ` Gerd Möllmann
2022-10-06 18:51           ` Philip Kaludercic
2022-10-06 19:35             ` Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-10-07  4:52             ` Gerd Möllmann
2022-10-06 18:00 ` Eli Zaretskii
2022-10-06 18:04 ` Stefan Kangas

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h70gu4ne.fsf@tcd.ie \
    --to=bug-gnu-emacs@gnu.org \
    --cc=58338@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    --cc=philipk@posteo.net \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.