While reading, the OS and most device drivers will anticipate that more contiguous data will be requested, and will usually fetch larger blocks in the background, caching them for later requests. Likewise, for writing, the buffers will be delayed and combined in order to produce larger, more efficient I/O access.
Solution: we do the same, but more.
In our particular case of handling a large consecutive collection of objects, we know beforehand that we will repeatedly read/write large contiguous blocks from/to the stream. Both BufferedStreamReader and BufferedStreamWriter have the option of having worker threads interacting with the I/O in the background, respectively called PreFetch and DelayedWriter. They’ll allow work blocks to queue up for I/O access until a certain configurable limit is reached. Besides the obvious benefit of being processed concurrently (the Read and Write calls won’t normally block), this will be useful in scenarios where the data flow is very irregular, i.e., when our sequence of elements contains objects that differ greatly and randomly in size or in serialization complexity (certain types are harder / take longer to process than others, due to the nature of the proto/msgPack protocols).
Sample usage:
No comments:
Post a Comment