unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: Re: weak hash tables
Date: Fri, 11 Nov 2011 21:30:05 +0100	[thread overview]
Message-ID: <87r51etnaq.fsf@gnu.org> (raw)
In-Reply-To: 878voaqpd2.fsf@pobox.com

Hi Andy,

Andy Wingo <wingo@pobox.com> skribis:

> While doing the recent retagging work I realized that I really wanted to
> kill weak pairs.  They look like pairs but you can't actually access
> their fields using car and cdr -- terrible things.

Agreed.  The reason was to keep the weak hash table API unchanged.

> To do that I had to reimplement the weak hash tables, to make them not
> use them.  I did that, reimplementing them as open-addressed hash
> tables, with robin hood linear probing on collision.  It seems to work
> well.  Besides the performance improvement you get with just scanning
> linearly through memory,

Could you provide an executive summary ;-) of:

  - how good ol’ weak hash tables related to the new weak sets and weak
    tables?

  - what the deal is wrt. performance, linear probing, and rehashing?

> open-addressed hash tables aren't structurally perturbed by the
> disappearing links.  It's a lot less messy, and uses less memory, and
> we have space to encode the actual hash values in the table.

That’s definitely a huge improvement.  :-)

> The one nasty thing there was adapting to the old interfaces.  In
> particular the hashx interface expects to be able to assoc down a list,
> but there are no assoc lists in the new weak tables.  Guess what I do?
> That's right, for weak hashx tables I make new association lists in the
> equal? handler, then pass that alist to the user's assoc function.
> Gross.
>
> Currently the new weak tables are only accessible under the old API.  I
> don't know whether to publicise the new API, or make a different API, or
> what.  If we hadn't coded the handle API into our hash tables I would
> replace the regular (strong) hash table implementation too.  I might
> still do that but it's not pressing.

FWIW I would keep the new C API private.

Is there any advantage to using the new weak table API instead of the
old weak hash table API?  The names suggest that they’re not quite
equivalent, but maybe that’s just the names?

Thanks for this brave endeavor!  :-)

Ludo’.




  parent reply	other threads:[~2011-11-11 20:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24 17:19 weak hash tables Andy Wingo
2011-10-28  9:02 ` Andy Wingo
2011-11-11 20:30 ` Ludovic Courtès [this message]
2011-11-15 21:33   ` Andy Wingo

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/guile/

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

  git send-email \
    --in-reply-to=87r51etnaq.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guile-devel@gnu.org \
    /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.
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).