whio  Update of "NewsPage"

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.


Artifact ID: ff6f2f1aa3a6ba8da184eaae26c49d2a0bc43a0f
Page Name:NewsPage
Date: 2011-05-23 18:50:52
Original User: stephan
Parent: bb54aadac7ee5dc927d6640d9d997c6b9247b075

ACHTUNG: AS OF 20110523, THIS PAGE IS NOW MAINTAINED IN THE NEW WIKI: http://whiki.wanderinghorse.net/wikis/whio/?page=NewsPage

whio News

Newest items are at the top...

22 Apr 2011:

  • Added an optimization to whio_epfs which reduces its dependency on gmtime(), saving tons of malloc() calls (on my system gmtime() and friends call malloc() very often).

19 Apr 2011:

  • All of the library code now compiles cleanly in C89 mode. The apps and test code still need C99.

18 Dec 2010:

17 Dec 2010:

  • Today i got a proof-of-concept implementation of the whio_epfs "namer" interface working. It uses a whio_ht instance to store inode/name mappings for whio_epfs instances. With this feature, whio_epfs now basically implements all the features of its genetic father, libwhefs.

7 Dec 2010:

  • Completely redefined the semantics of whio_dev::iomode() and whio_stream::iomode(). Sorry about that, but client code will have to adjust for it. This is a subtle but notable improvement, including that it now supports both read and write mode for streams (assuming they can do both). Note that older code is likely to compile just fine, but the semantics are now different!

3 Dec 2010:

  • Introducing whio_ht, which is similar to whio_udb but is based on whio_vlbm and supports variable-length keys and values.

15 March 2010:

  • After 4 or 5 straight nights of hacking (including one 31-hour marathon session, with only a 5-hour break to go to work), i am pleased to add whio_udb to the public API. It is a whio_dev-based hashtable with amortized O(1) performance for all operations :-D.

11 March 2010:

  • Woohoo! Early this morning i got a new whio_dev-based "micro database" (uDB) API working. It is a storage-based hashtable with amortized O(1) insert/search/remove, uses arbitrary whio_dev storage, has constant memory requirements (only 1-2 allocations), and will be a perfect match for use as an inode-to-name mapper for whio_epfs. :-D

10 March 2010:

  • After nearly 18 months of waiting for a solution to this problem to surface, the search times for the next-free inode and data block objects in whio_epfs are now O(1). (There's a small amount of new i/o overhead to possibly read/modify/flush one or two neighboring records.) Formerly these ops were O(1) average case but worst-case O(N) (N=block/inode count). The changes required no new memory allocations and removes the only two remaining notable performance bottlenecks in the library :).

2 March 2010:

  • Added an interface which allows client applications to replace the memory allocator used by the whio internals. This obsoletes the older (and un-safer) "static allocators".

19 Feb 2010:

13 Dec 2009:

8 June 2009:

  • Now compiles with gcc's -pedantic and -fstrict-aliasing flags. Seems to work, too.

9 March 2009:

30 Dec 2008:

  • Experimentation has shown that we can, with only a few minor workarounds, use SWIG to generate script bindings for whio_dev. Once that works it should be easy to make whefs (which uses whio extensively) scriptable.