guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pass at srfi-89 implementation


From: Ludovic Courtès
Subject: Re: pass at srfi-89 implementation
Date: Mon, 11 Aug 2008 13:48:13 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Hi Julian,

"Julian Graham" <address@hidden> writes:

> Okay, I've tried -- at length.  And so far I haven't been able to top
> the performance of the reference implementation.  In fact, it actually
> seems to be fairly efficient

Did you run some sort of "benchmark"?

> From what I can see, there are
> only a few areas in which the reference implementation could be
> improved by Guile-specific features:
>
> * Native hash tables (Marc's code has its own hash table implementation)
>    * Use of `hashq-get-handle' (the reference implementation relies on
> the identity of an `undefined' object)

The reference implementation strives to create a perfect hash table,
while Guile's built-in hash tables may not be perfect all the time
(there can be collisions, although tables are automatically resized once
in a while).  So, theoretically, the reference implementation's solution
is more efficient.

OTOH, as is often the case with Guile, it may turn out to be faster to
use Guile's built-in hash tables, especially since they may end up being
"perfect" (i.e., collision-free) in most cases here; in addition,
running one `make-perfect-hash-table' for each `lambda*' at
initialization time may turn out to be more costly than just
`make-hash-table'.  Could you try that out?

> * Symbol generation for naming run-time helper functions (the
> reference implementation explicitly exports bindings for helper
> functions)

Hmm, what are you referring to precisely?

Also:

 * use Guile's `string-hash' in `$hash-keyword' (unless Guile's hash
   tables are used, that is).

Overall, it may indeed be wise to use the reference implementation.
However, we'd need a copyright assignment from Marc and/or licensing
under LGPLv2+.

Thanks,
Ludovic.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]