Sbinary performance and Buffered IO

This is kinda a “Well, duh” moment. It’s obvious in retrospect, but I completely failed to spot it up front, so I thought I’d share.

I noticed that SBinary performance really really sucked. We’re using it at work for saving application state, and reading and writing a file of only 900kb took about two seconds! This was bad.

Some quick performance testing suggested that this was almost entirely IO bound. Reading and writing the corresponding amount of data from a byte array took fairly little time – only about 200ms for writing, 300ms for reading. So, what was I doing wrong?

After a few seconds of head scratching I realised the problem. You see, RandomAccessFile implements the DataInput and DataOutput interfaces. This is useful for small things, but for doing non-trivial binary input and output? Not so much.

The problem is that the reads and writes for these implementations are totally unbuffered. This should have been obvious, but for some reason didn’t occur to me. Oops. I’m now buffering reads and writes explicitly (currently in a pretty stupid way, but oh well). It’s a lot faster now.

This entry was posted in programming and tagged , , on by .

One thought on “Sbinary performance and Buffered IO

  1. Iulian

    That’s a good one. My favorite performance hog is string concatenation… My combinators were building fairly involved failure messages (including calling ‘toString’ on XML nodes :(), which appear a lot even on successful paths (e.g. the stop condition for rep). Profiling revealed hotspots in arraycopy (called from StringBuilder resize). When I switched to proper error objects, execution time more than halved. Duuhh.

Comments are closed.