Okay, it had to come to this eventually . . . I'm porting blosxom to C.
I've started various PHP ports in the past (since even phposxom was too icchhk for me), but none of them came to much. When it comes down to it, the filesystem is a fantastically inefficient database, since you have disk lookups (msec range) rather than memory lookups (nsec range). When you pile an interpreted language with all its overhead atop that, you have abysmal page-generation times. Dynamic sites done in interpreted languages really need optimized database backends.
But give up? On blosxom? Never! This is a holy war: depend on something that may or may not change, or depend on something that has remained substantially unchanged since the seventies and eighties: pick one.
And so begins cosxom (I would have said "closxom", but that has shades of Clostridium to me . . . that's what microbiology will do to you!), the first (that I know of) C port of blosxom. So far it just pulls in a header and footer around an alphabetical-by-path collection of entries (sorting methods will come later). I know that the benchmark is far from fair at the moment, but a minimal blosxom install builds a page based on a highly-nested data directory of forty-one entries in 0.894s of user time and 0.159s of system time, while the current cosxom 0.01pre-a builds the a page in 0.007s user time and 0.019s system time. You can't tell me that two orders of magnitude is going to disappear with a sort and some filtering.
Oh, and if you'd like to see the only PHP blosxom-like CMS I'm going to keep pursuing, check out tumble on SourceForge.