unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Joris van der Hoeven <TeXmacs@math.u-psud.fr>
Cc: Joris van der Hoeven <TeXmacs@math.u-psud.fr>
Subject: Re: Efficiency and flexibility of hash-tables
Date: Sat, 8 Feb 2003 16:14:34 +0100 (MET)	[thread overview]
Message-ID: <Pine.GSO.3.96.1030208160743.22945E-100000@anh> (raw)
In-Reply-To: <1044716148.1033.177.camel@localhost>


> > My question was: is the number of slots automatically adapted
> > as a function of the number or entries, or is it not?
> > If you cannot have a good estimate for the number of entries,
> > then this auto-adaptation may be important.
> > In fact, I think that a good low level implementation of
> > general purpose hash tables should have this feature.
> 
> I agree. I once developed (in Ada) for a debugging system, a hash
> table where the hash entries were balanced trees instead of lists.
> This could maybe be a good approach to reach good performance as
> balanced trees are quite good from this point of view. (like the
> new Reiser file system in Linux is using)
> 
> Your idea, about adaptive hash table length, could easily be made into
> guile but from my opinion not as a general solution, as there will be
> a lot of reshuffling of every item each time the vector length changes.

That is not really true: the reshuffling only takes place
when the number of entries changes in an important way.
Also, shuffling is linear in time. So if it only occurs
after adding or removing a proportional number of entries,
then the overall running time remains linear.
This is better than using a O(log n) overhead for all operations.
However, the price to pay is rather that the shuffling can occur
at arbitrary moments. But this is already the case for garbage
collection anyway. In fact, I implemented this kind of
hash tables in TeXmacs.

> I guess somewhere out there, a balanced tree solution may exist for guile,
> otherwise I could try to find my old ada-source and give it a try. The
> disadvantage with the balanced tree solution though is that it's not
> enough with a hash function (and equal?), it also needs a comparision
> (<) function.

So does there exist an adaptive-number-of-slots solution in guile?
If I understand you well, this is certainly not the case for
the standard implementation... :^(((



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user


  reply	other threads:[~2003-02-08 15:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-08 11:00 Efficiency and flexibility of hash-tables Joris van der Hoeven
2003-02-08 13:57 ` Roland Orre
2003-02-08 14:14   ` Joris van der Hoeven
2003-02-08 14:55     ` Roland Orre
2003-02-08 15:14       ` Joris van der Hoeven [this message]
2003-02-08 15:31         ` Mikael Djurfeldt
2003-02-11 11:14           ` Joris van der Hoeven
2003-02-11 11:28             ` Joris van der Hoeven
2003-02-11 12:50               ` Mikael Djurfeldt
2003-02-08 15:44         ` Roland Orre
2003-02-10  9:55           ` Andreas Rottmann
2003-02-10 14:24             ` Greg Troxel
2003-02-10 15:00               ` Roland Orre
2003-02-10 16:52                 ` Mikael Djurfeldt
2003-02-10 17:09                   ` Roland Orre
2003-02-10 17:11                   ` Mikael Djurfeldt
2003-02-11 13:59                     ` Resizing hash tables in Guile Mikael Djurfeldt
2003-02-11 17:34                       ` Roland Orre
2003-02-12 11:41                         ` Marius Vollmer
2003-02-12 16:10                       ` Marius Vollmer
2003-02-12 17:53                         ` Mikael Djurfeldt
2003-02-12 20:17                           ` Roland Orre
2003-02-13  9:35                             ` Mikael Djurfeldt
2003-02-13 13:55                               ` Harvey J. Stein
2003-02-13 14:24                                 ` Joris van der Hoeven
2003-02-13 18:30                                   ` Harvey J. Stein
2003-02-13 20:02                                     ` Paul Jarc
2003-02-13  9:52                             ` Joris van der Hoeven
2003-02-12 20:55                       ` Rob Browning
2003-02-13 10:43                         ` Mikael Djurfeldt
2003-02-12 20:47       ` Efficiency and flexibility of hash-tables Paul Jarc
2003-02-12 21:58         ` Roland Orre

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=Pine.GSO.3.96.1030208160743.22945E-100000@anh \
    --to=texmacs@math.u-psud.fr \
    /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).