greatly differing processing time between java and Linux while calculating hashes?
> As far as I could extract from that code (which I find pretty badly
readable btw.) you are measuring digest calculation and IO.
Well, if I understand you, you will have to read in the file you are
checksumming anyway, right?
I used FileInputStream's read(byte) method in a straight forward way,
which is, byte, what you must feed a MessageDigest's update method. So,
what do you mean?
> What measures did you take to ensure there are no effects from OS buffering?
What do you mean? What extra measure should I take to ensure there are no
effects from OS buffering?
> Also, why are you comparing apples (Java) and oranges (Linux) - at
> least in the subject?
Because I am trying to extract sugar from them in the most efficient way
> Are you aware that the JVM has some startup time
> which can be significant when measuring run once applications?
Yes, and this is why I am just timing the method call and testing different
block sizes for the buffer ...
Still guys (to me) a difference of more than 25% in processing time is
significant and I don't think that what you consider to be my odd style to code
is causing it
Re: greatly differing processing time between java and Linux while calculating hashes?
On Mon, 10 Sep 2012 01:45:36 +0000 (UTC),
firstname.lastname@example.org wrote, quoted or indirectly quoted
someone who said :
> Well, if I understand you, you will have to read in the file you are
>checksumming anyway, right?
You want in both cases to read it into RAM, then start your clock,
then do your computation, then stop your clock, so that you measuring
the difference in computation, not i/o.
JVMs take a while to get warmed up. When doing benchmarks you want to
run a few laps before you turn on the clock.
Roedy Green Canadian Mind Products http://mindprod.com
The iPhone 5 is a low end Rolex.
|All times are GMT. The time now is 09:30 AM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.