avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Carey (JIRA)" <j...@apache.org>
Subject [jira] Updated: (AVRO-392) Binary Decoder Performance and flexibility overhaul
Date Fri, 12 Feb 2010 10:50:28 GMT

     [ https://issues.apache.org/jira/browse/AVRO-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Scott Carey updated AVRO-392:

    Attachment: AVRO-392.patch

This patch changes several things:

The Decoder API is now unchanged.  All new constructor types and variants are hidden behind

I have removed the use of these old constructors and init methods from all tests and the rest
of the code and replaced it with the factory.
We can decide to deprecate the old constructors and and the init(InputStream) method on Decoder
and put that in another patch if we wish.  I had included that deprecation at first, but have
several other things dependant on this patch and wish to get it committed soon and leave details
like that for another ticket.

Unit tests in TestBinaryDecoder were significantly enhanced.  There is 92.5% instruction coverage
on BinaryDecoder from this class (with trivial items left) as measured by EclEmma code coverage
plugin in Eclipse.  This single unit test class by itself covers 11% of all of org.apache.avro.*.*

This patch does not have a "DirectBinaryDecoder", but is build to easily bolt that on.  I
have a separate patch with that in it, or we can commit this and do that addition in another
ticket.   Adding it is as easy as adding a factory method, and svn cp'ing an old BinaryDecoder
to a new DirectBinaryDecoder and then applying a patch to change its name and some signatures.

The Performance test has been modified to be more consistent and balance time between tests
better. The first test was too fast because it had not compiled other variations of Decoder
ant Test and was able to inline the decoder calls into the test -- once the polymorphism of
the Decoder interface is seen by the JIT, it has to deoptimize some.  
Results on my laptop are:
ReadInt: 475 ms, 105.22084803794685 million entries/sec.  264.7735331687679 million bytes/sec
ReadLongSmall: 742 ms, 67.30978926651177 million entries/sec.  169.37566131867953 million
ReadLong: 964 ms, 51.819754312180855 million entries/sec.  226.4181253063843 million bytes/sec
ReadFloat: 408 ms, 122.33463415827654 million entries/sec.  489.34343001847253 million bytes/sec
ReadDouble: 412 ms, 121.10613499458655 million entries/sec.  968.8539242020922 million bytes/sec
ReadBoolean: 369 ms, 135.35646124067733 million entries/sec.  135.36187549912694 million bytes/sec
RepeaterTest: 1039 ms, 8.017210110940177 million entries/sec.  311.1342336699734 million bytes/sec
NestedRecordTest: 1766 ms, 28.312137923146135 million entries/sec.  71.243531384288 million
ResolverTest: 1193 ms, 6.9835422054685 million entries/sec.  271.0193474205395 million bytes/sec
MigrationTest: 3785 ms, 2.2012176566554804 million entries/sec.  85.4254983051707 million
GenericReaderTest: 3243 ms, 2.5692238249338963 million entries/sec.  99.70718926358578 million
GenericReaderTestWithDefaultTest: 6494 ms, 1.283021087397709 million entries/sec.  49.791857427457266
million bytes/sec
GenericReaderTestWithOutOfOrderTest: 3257 ms, 2.5579396506737884 million entries/sec.  99.26926973017773
million bytes/sec
GenericReaderTestWithPromotionTest: 3415 ms, 2.439907076813885 million entries/sec.  94.68862709916043
million bytes/sec

Results with the old decoder:
ReadInt: 2025 ms, 24.68210680539985 million entries/sec.  62.109066280835975 million bytes/sec
ReadLongSmall: 1519 ms, 32.91266558362055 million entries/sec.  82.8201151679994 million bytes/sec
ReadLong: 2455 ms, 20.360469903356993 million entries/sec.  88.96181556753385 million bytes/sec
ReadFloat: 1268 ms, 39.41542199333249 million entries/sec.  157.66326459020968 million bytes/sec
ReadDouble: 1266 ms, 39.472365002538076 million entries/sec.  315.7804989149047 million bytes/sec
ReadBoolean: 555 ms, 89.94391097711467 million entries/sec.  89.94750873355376 million bytes/sec
RepeaterTest: 2387 ms, 3.490798376127346 million entries/sec.  135.4719238517502 million bytes/sec
NestedRecordTest: 3346 ms, 14.942269049301121 million entries/sec.  37.600128144899365 million
ResolverTest: 2498 ms, 3.3354787991155557 million entries/sec.  129.4442363022417 million
MigrationTest: 5160 ms, 1.6148558208740609 million entries/sec.  62.66979677001705 million
(Generic tests are harder to replace the decoder in).

> Binary Decoder Performance and flexibility overhaul
> ---------------------------------------------------
>                 Key: AVRO-392
>                 URL: https://issues.apache.org/jira/browse/AVRO-392
>             Project: Avro
>          Issue Type: Improvement
>          Components: java
>            Reporter: Scott Carey
>            Assignee: Scott Carey
>            Priority: Critical
>             Fix For: 1.3.0
>         Attachments: AVRO-392-preview.patch, AVRO-392.patch, AVRO-392.patch, AVRO-392.patch,
> BinaryDecoder has room for significant performance improvement.  [AVRO-327|https://issues.apache.org/jira/browse/AVRO-327]
has some preliminary work here, but in order to satisfy some use cases there is much more
work to do.
> I am opening a new ticket because the scope of the changes needed to do this the right
way are larger.
> I have done a large bulk of a new implementation that abstracts a 'ByteSource' from the
BinaryDecoder.  Currently BinaryDecoder is tightly coupled to InputStream.  The ByteSource
can wrap an InputStream, FileChannel, or byte[] in this version, but could be extended to
support other channel types, sockets, etc.  This abstraction allows the BinaryDecoder to buffer
data from various sources while supporting interleaved access to the underlying data and greater
flexibility going forward.
> The performance of this abstraction has been heavily tuned so that maximum performance
can be achieved even for slower ByteSource implementations.
> For readers that must interleave reads on a stream with the decoder, this includes a
> {code}
> public InputStream inputStream();
> {code}
> method on the decoder that can serve interleaved reads.  
> Additionally it will be necessary to have a constructor on BinaryDecoder that allows
two BinaryDecoders to share a stream (and buffer).
> Performance results on this new version is better than previous prototypes:
> *current trunk BinaryDecoder*
> {noformat}
> ReadInt: 983 ms, 30.497877855999185 million entries/sec
> ReadLongSmall: 1058 ms, 28.336666040111496 million entries/sec
> ReadLong: 1518 ms, 19.75179889508437 million entries/sec
> ReadFloat: 657 ms, 45.61031157924184 million entries/sec
> ReadDouble: 761 ms, 39.387756709704355 million entries/sec
> ReadBoolean: 331 ms, 90.4268145647456 million entries/sec
> RepeaterTest: 7718 ms, 3.886725782038378 million entries/sec
> NestedRecordTest: 1884 ms, 15.91964611687992 million entries/sec
> ResolverTest: 8296 ms, 3.616055866616717 million entries/sec
> MigrationTest: 21216 ms, 1.4139999570144013 million entries/sec
> {noformat}
> *buffering BinaryDecoder*
> {noformat}
> ReadInt: 187 ms, 160.22131904871262 million entries/sec
> ReadLongSmall: 372 ms, 80.4863521975457 million entries/sec
> ReadLong: 613 ms, 48.882385721129246 million entries/sec
> ReadFloat: 253 ms, 118.16606270679061 million entries/sec
> ReadDouble: 275 ms, 108.94314257389068 million entries/sec
> ReadBoolean: 222 ms, 134.85327963176064 million entries/sec
> RepeaterTest: 3335 ms, 8.993007936329503 million entries/sec
> NestedRecordTest: 1152 ms, 26.0256943004597 million entries/sec
> ResolverTest: 4213 ms, 7.120659335077578 million entries/sec
> MigrationTest: 15310 ms, 1.9594884898992941 million entries/sec
> {noformat}
> Performance is 2x to 5x the throughput of trunk on most tests.  

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message