Take

Baker's dilemma

So far, this site is fried, not baked. I would love to bake it, but even more so, I would love to be able to type stuff into it and have it show up soon. Minimizing friction and all that. And my esoteric metadata and reticence towards implementing a standard posting API makes using a weblog posting app unlikely.

Right now, every time a post is added or edited or removed, a change is made to the database (SQLite), all the entries are read into memory and massaged into a form that will make pretty much any query fast (like maintaining ordered lists of post IDs and a dictionary of post IDs to everything about that post), and the previous instance of this form is atomically swapped out. This is slow-and-dumb, but it's not slow-and-dumb enough to make all this take measurable time, even on the Turing's bookend of a server this runs on, and it only happens when changes are actually made which is almost never. And showing a post never goes to the database/disk, it just consults this massaged form and does data structure things, which gains a lot of performance back, since that happens way more than changes.

Eventually my preference will be to have every popular thing that can be served baked up front, and when a change happens, to have the baked things that are affected re-baked. This gets tricky when next/prev links are involved, or when deleting a post shifts all subsequent pages, if you're doing this to post-list-pages too.

Previous post: Typefaces Following post: Retro Game Mechanics Explained