30

Possible Duplicate:
How do you determine the ideal buffer size when using FileInputStream?

When reading raw data from a file (or any input stream) using either the C++'s istream family's read() or C's fread(), a buffer has to be supplied, and a number of how much data to read. Most programs I have seen seem to arbitrarily chose a power of 2 between 512 and 4096.

  1. Is there a reason it has to/should be a power of 2, or this just programer's natural inclination to powers of 2?
  2. What would be the "ideal" number? By "ideal" I mean that it would be the fastest. I assume it would have to be a multiple of the underlying device's buffer size? Or maybe of the underlying stream object's buffer? How would I determine what the size of those buffers is, anyway? And once I do, would using a multiple of it give any speed increase over just using the exact size?

EDIT
Most answers seem to be that it can't be determined at compile time. I am fine with finding it at runtime.

Community
  • 1
  • 1
Baruch
  • 20,590
  • 28
  • 126
  • 201
  • I believe the buffer size depends on either the compiler or the machine (sorry, I don't know which or maybe it is both). The only way to know is to try by reading in various sizes of data. It should be fast, so do it 100 times and take the average. It _shouldn't_ be a straight line. My guess is you should notice when you've crossed the point where another buffer of data has to be read. (Alternatively, you can dig through C/C++'s source code...) – Ray May 22 '12 at 08:33
  • 14
    If in doubt, always make your buffers size a power of two. Other programmers will think you did it for some clever reason. ;-) – Frerich Raabe May 22 '12 at 08:40
  • Re edit: Run time does not help much. You need profiling done at development time, unless you can afford extreme "warm-up runs" with lots of data every time your adaptive buffered code is started. – Jirka Hanika May 23 '12 at 12:21

6 Answers6

23

SOURCE:
How do you determine the ideal buffer size when using FileInputStream?

Optimum buffer size is related to a number of things: file system block size, CPU cache size and cache latency.

Most file systems are configured to use block sizes of 4096 or 8192. In theory, if you configure your buffer size so you are reading a few bytes more than the disk block, the operations with the file system can be extremely inefficient (i.e. if you configured your buffer to read 4100 bytes at a time, each read would require 2 block reads by the file system). If the blocks are already in cache, then you wind up paying the price of RAM -> L3/L2 cache latency. If you are unlucky and the blocks are not in cache yet, the you pay the price of the disk->RAM latency as well.

This is why you see most buffers sized as a power of 2, and generally larger than (or equal to) the disk block size. This means that one of your stream reads could result in multiple disk block reads - but those reads will always use a full block - no wasted reads.

Ensuring this also typically results in other performance friendly parameters affecting both reading and subsequent processing: data bus width alignment, DMA alignment, memory cache line alignment, whole number of virtual memory pages.

Community
  • 1
  • 1
ravi
  • 3,304
  • 6
  • 25
  • 27
4
  1. At least in my case, the assumption is that the underlying system is using a buffer whose size is a power of two, too, so it's best to try and match. I think nowadays buffers should be made a bit bigger than what "most" programmers tend to make them. I'd go with 32 KB rather than 4, for instance.
  2. It's very hard to know in advance, unfortunately. It depends on whether your application is I/O or CPU bound, for instance.
unwind
  • 391,730
  • 64
  • 469
  • 606
1
  1. I think that mostly it's just choosing a "round" number. If computers worked in decimal we'd probably choose 1000 or 10000 instead of 1024 or 8192. There is no very good reason.

One possible reason is that disk sectors are usually 512 bytes in size so reading a multiple of that is more efficient, assuming that all the hardware layers and caching cause the low level code to actually be able to use this fact efficiently. Which it probably can't unless you are writing a device driver or doing an unbuffered read.

jcoder
  • 29,554
  • 19
  • 87
  • 130
0

No reason that I know of that it has to be a power of two. You are constrained by the buffer size having to be within max size_t but this is unlikely to be an issue.

Clearly the bigger the buffer the better but this is obviously not scalable so some account must be taken of system resource considerations either at compile time or preferably at runtime.

Component 10
  • 10,247
  • 7
  • 47
  • 64
0

1 . Is there a reason it has to/should be a power of 2, or this just programer's natural inclination to powers of 2?

Not really. It should probably be something that goes even in the size of the data bus width to simplify memory copy, so anything that divies into 16 would be good with the current technology. Using a power of 2 makes it likely that it will work well with any future technology.

2 . What would be the "ideal" number? By "ideal" I mean that it would be the fastest.

The fastest would be as much as possible. However, once you go over a few kilobytes you will have a very small performance difference compared to the amount of memory that you use.

I assume it would have to be a multiple of the underlying device's buffer size? Or maybe of the underlying stream object's buffer? How would I determine what the size of those buffers is, anyway?

You can't really know the size of the underlying buffers, or depend on that they remain the same.

And once I do, would using a multiple of it give any speed increase over just using the exact size?

Some, but very little.

Guffa
  • 687,336
  • 108
  • 737
  • 1,005
0

I think Ideal size of Buffer is size of one block in your hard drive,so it can map properly with your buffer while storing or fetching data from hard drive.

Rup
  • 1
  • 3