fenfire-dev
[Top][All Lists]
Advanced

[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
 







reply via email to

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