On Jul 30, 2010, at 10:17 AM, Nikolaos Giannopoulos wrote:
> Ok. But keep in mind whether or not this fixes the problem or not you should
> ALWAYS use buffering. And you don't have to take my word for it just run a
> timed test yourself. Again I know this didn't resolve this issue but good to
> keep your code at its best... .
>
Not true. I hate "always".
FileInputStream fis = new FileInputStream("data.dat");
byte data[] = new byte[4096];
int cnt = fis.read(data);
That works just peachy without buffering, its zippy fast. If you were using a
BufferedInputStream, you would end up with an extraneous memory copy.
Buffering is important if you were doing:
for(int i = 0; i < data.length; i++) {
int d = fis.read();
if (d == -1) {
break;
}
data[i] = d;
}
Those individual I/O's on a raw file will kill you. A BufferedInputStream would
be much faster. In the previous case, you're effectively doing the buffering
yourself.
What you should ALWAYS strive to do is understand why things are done, and when
to use them rather than blindly following idioms and patterns you find spread
as folklore.
With regards to the streaming resolution, if you look at the code, it's already
doing a 512 byte block read, so a buffered stream is likely unnecessary at this
point.
Regards,
Will Hartung
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
