[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fenfire-dev] Functional API success
From: |
Tuomas Lukka |
Subject: |
[Fenfire-dev] Functional API success |
Date: |
Tue, 9 Sep 2003 20:52:22 +0300 |
User-agent: |
Mutt/1.5.4i |
Yes!
The Functional API works and with the Lifo priorityqueue it gives an extremely
concrete speedup to the case I've been discussing (i.e. start from main node,
go to "Hypertext Conferences", then go to one of the conferences.
Because the caches later in the stream call back to the superlazy cache
to inform it that a given value was used, the cache is able to recompute the
values in the order they are needed, which is quite nice.
You can test and examine the code yourself: I've placed it in the arch
repository
on himalia: the archive is named
address@hidden
and is located at
sftp://himalia.it.jyu.fi/home/lukka/address@hidden
>From there, you need
1) libvob: the libvob--kuu--0.1 branch contains some things I've not committed
to CVS
yet (the change to use Lifo priority queues, as it would make the CVS fenfire
really
slow)
2) fenfire functional branch: fenfire--functional--0.1. You can examine the
differences
between it and fenfire--kuu--0.1 (the main branch that follows CVS).
If anyone wants to try, you can send me merge requests or arch changesets to
merge to
any of the *--kuu--0.1 branches (or other branches).
To avoid a total versioning nightmare, PLEASE DO NOT COMMIT ANYTHING FROM CVS
TO ARCH
OR VICE VERSA. I'll take care of syncing them up.
Benja: do you have still objections to the functional_futureproof_api so strong
that
I shouldn't commit the code from the branch to CVS? It's easy to change the
details
of the API and the way it's called, but the basic idea that it exists and can
be used
is vital.
Tuomas
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Fenfire-dev] Functional API success,
Tuomas Lukka <=