This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Scheme style auto-resizing hashtable (fwd)



jglascoe@jay.giss.nasa.gov writes:
> On Fri, 6 Nov 1998, Maciej Stachowiak wrote:
> 
> > 
> > jglascoe@jay.giss.nasa.gov writes:
> > > 
> > > woops, you're right, that is somewhat pointless.  let me change it a bit
> > > 
> > 
> > I think this version is pointless too...
> <snip>
> > If it is really important for the memory to be incrementally
> > reclaimable, just make sure dictionary-insert-alist! is tail recursive
> > and the call to it is the only reference to the alist.
> > 
> 
> you know this is all taking place in C, so I'm doing loops instead of
> recursion.  

loops are approximately equal to tail recursion.

> Also, my internal resize procedure does this same trick; it
> deletes the old buckets as it fills the new ones.  I've timed resize both
> with this deletion and without it.  The result: Guile likes it when I
> delete things; it praises me by using less memory *and* running faster.
> Maybe this deletion business is only good with the current GC.  I don't
> know.  But it does seem to work.
> 

It's probably helping because things can get GCd incrementally instead
of all in one bunch. If you changed all references to the current
bucket to point to the currently unprocessed tail only, it would have
the same effect. I'd need to look at your code to be more specific. I
hope to get around to that this weekend.

I am a fan of minimal APIs (in the sense of "as small as possible but
no smaller"), and I think performance gains in particular cases that
are likely dependent on Guile's current GC (which is already getting
rewritten) are a bad reason to add more calls to an API.

 - Maciej