Loading Tinderbox Faster

Small Tinderbox files load quickly, but streaming thousands of notes and links from your disk is bound to take a few seconds. In the big picture, it’s an acceptable cost: first, because it’s only a minute or two a day, and second, because there isn’t a free lunch – picking up and handling thousands of objects is a lot of work.

But making things faster is nice. And, because you’re probably sitting there waiting for Tinderbox to load so you can write stuff down, the delay has more emotional weight than, say, the minute you lost getting coffee, or waiting at a traffic light, or reading the invitation to a client’s product launch.

Most of the time, I resist optimizing Tinderbox. First, my reflexes already lean too far on the side of performance. Habits, formed at a time when computers were much slower and much smaller, lead me to make lots of little optimizations in the code and the architecture that probably are unwarranted but that, collectively, help make the code fast. A lot of this adds complexity, things are already pretty complex under the hood, and the we don’t want to make the trade-off worse.

But, after a user twittered in praise of a very slight speedup in load times in Tinderbox 4.5.3, I took out the profiler and studied Tinderbox 4.6 . Things looked reasonable: parsing XML takes time but XML has proved its worth for Tinderbox many times over.

And then, there it was: one routine of the XML loader was doing tens of thousands of memory allocations. OK: we’re building complicated objects from their flattened disk representations, we expect allocations. But there did seem to be a lot of them.

Short answer: small changes in memory strategy in Unicoder, XMLReader, and CeresReader save about 100,000 allocations every time I open my weblog. And now, with Tinderbox, they save time whenever you open your big documents. It won't matter unless you've got thousands of notes, but it’s nice to have.