• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

BufferedReader default size

 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does anyone know what the BufferedReader default size is?
I'm reading in large amounts of text (sometimes greater than 2MB) from the disk, and I was wondering if changing the buffer size might optimize the read times a little bit.
Anyone have a suggestion on a test buffer size?
 
Ranch Hand
Posts: 1179
Mac OS X Eclipse IDE
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are two constructors, one with a default buffer size of 8192 characters, and one that lets you specify the buffer size:
public BufferedReader(Reader in, int sz)
public BufferedReader(Reader in)
/Rene
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
and I was wondering if changing the buffer size might optimize the read times a little bit.

Sure, it might. Probably not by a huge amount, but it can't hurt to try if you have good reason to believe that file reading is your main consumer of machine time currently. There's no single ideal number - the default 8192 is as good a starting point as any. Try other widely-separated values like 1000, 3000, 20000, 50000. If you see a significant difference in performance, continue to change values in the direction that seems most promising. It shouldn't take long to reach a point (or rather, a general range) where you're no longer able to find further substantial improvements. (Chances are, you were in this range to begin with.)
If you find that your application is sensitive to this buffer size, and if you application is intended to ever be run on any other machines, you should probably make the buffer size a configurable parameter, read from a properties file or the like, so it will be possible to tune the performance on individual machines.
 
Micah Wedemeyer
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the quick replies!
The reason I encountered this was due to the fact that I noticed some discrepencies in the performance of my system. Maybe someone here can help me...
I have a system that has to read large amounts of text from the hard disk (like I said earlier). Usually, it is multithreaded, so there are multiple threads vying for disk access. I've heard that on many applications, multi-threading can significantly improve speed.
However, on my system, it seems to degrade speed by about 10-20% My theory is that as the different threads are swapped in and out, the disk must move from one read position to another. Therefore, the speed degradation is due to seek times while the read head is moving. Does this sound reasonable?
I talked to a colleague of mine, and he suggested adjusting the buffer sizes. He said that larger buffer sizes could significantly improve speed. Would it solve my problem? Would I be better off just running everything in serial rather than in parallel?
I guess I should run some empirical tests to make sure, but I'd love any input or advice.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, testing would be best. But my gut feeling is that if your threads don't really have anything time-consuming to do other than waiting to read from disk, then multiple threads are probably counterproductive for you, and should be eliminated. If the threads do have some other (time-consuming) things to do, keep them, and increasing buffer sizes could well alleviate the problem. (Or make it worse if you increase them so much that your machine needs to use virtual memory for the buffers.) Try making the maximum number of allowed threads a configurable parameter, so that you can tune it later as desired. Or course, if the optimum value does turn out to be 1 then your design could have been simpler to begin with. :roll: . But hindsight's 20/20 after all...
 
reply
    Bookmark Topic Watch Topic
  • New Topic