[
https://issues.apache.org/jira/browse/AVRO-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804627#action_12804627
]
Scott Carey commented on AVRO-354:
----------------------------------
Ah, the JVM hadn't gotten around to fully optimizing ReadInt until it was used
from more call sites or something.
When running microbenchmarks and trying to figure out why these sort of things
vary from run to run, or in different run orders, it is useful to have the JVM
print out its compilations: -XX:+PrintCompilation
It is also useful to print GC -- if a gc runs inside of the benchmark, it will
disturb the results. Of course, in the real world that isn't to be discarded
(code that reduces GC frequency is good!) but it sure is nice to know if its
causing variability in a test.
If each phase of the test starts or finishes with clear log output, then it is
easy to see when JIT compiling or GC is affecting a test.
I just saw this blog post, which adds some useful context to some of the
oddities of the JVM / JIT http://java.sys-con.com/node/1118894
> Performance improvement to BinaryDecoder.readInt()
> --------------------------------------------------
>
> Key: AVRO-354
> URL: https://issues.apache.org/jira/browse/AVRO-354
> Project: Avro
> Issue Type: Improvement
> Components: java
> Affects Versions: 1.3.0
> Environment: koli...@koliver-ws4:~$ uname -a
> Linux koliver-ws4 2.6.24-26-generic #1 SMP Tue Dec 1 17:55:03 UTC 2009 x86_64
> GNU/Linux
> Reporter: Kevin Oliver
> Priority: Minor
> Attachments: AVRO-354-results.csv, AVRO-354.patch
>
>
> Able to get a 3-7% improvement on Perf -i by creating a specialized version
> of BinaryDecoder.readInt() that uses the same code as readLong() but uses
> ints instead of long for all its math and bit arithmetic.
> The performance improvement is larger on a 32-bit VM (around 7%) than on a
> 64-bit VM (around 3%).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
