[Top][All Lists]
[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.