I don't understand what this person is "really" doing ...
"100 test loops" ??? Does that mean; 100 iterations of the loop were
run to extend the execution time, 100 iterations were done to warm up
the code, etc, etc.
Also note that a good (server) JIT compiler and JVM could easily reduce
this micro-benchmark into a no-op (a very close to a no-op) since
nothing is done externally with tBytes once it is gotten from buf.
I don't know how else to say this .... this micro-benchmark is just
plain poorly written to the extent that I don't think anyone should
believe the results it reports. It suffers from too many of the "how not
to write a micro-benchmark" symptoms.
charlie ...
Jeanfrancois Arcand wrote:
>
>
> -------- Original Message --------
> Subject: Re: Performance comparision of Mina vs. java.nio ByteBuffer use
> Date: Thu, 05 Jul 2007 09:46:44 +0200
> From: Michael Bauroth <michael.bauroth_at_falcom.de>
> Reply-To: dev_at_mina.apache.org
> Organization: Falcom GmbH
> To: dev_at_mina.apache.org
> References: <468B96C1.6000402_at_falcom.de>
> <768dcb2e0707041927m71003107k88691612862aa49d_at_mail.gmail.com>
>
> Extending the test with Grizzly and after running 100 test loops of each
> method I have now correct results (not normalized):
>
> Loop: 100 Mina(avg.): 691 Nio(avg.): 669 Grizzly(avg.): 691
>
> Loop: 100 M (avg.): 699 N (avg.): 662 G (avg.): 686
> Loop: 100 M (avg.): 708 N (avg.): 670 G (avg.): 698
>
> Mina and Grizzly have the exact same values (used for Grizzly not-direct
> viewbuffers), pure Nio is naturally 3-4% quicker.
>
> Used Java 6 and Win XP as testbed.
>
> Best Regards
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>