[
https://issues.apache.org/jira/browse/KAFKA-4424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15691571#comment-15691571
]
Michael Andre Pearce (IG) edited comment on KAFKA-4424 at 11/23/16 11:22 PM:
-----------------------------------------------------------------------------
Hi Matthias,
Thanks for putting together some initial tests.
When we took your test and ran it this evening (with the same parameters) we
get:
# Run complete. Total time: 01:40:11
Benchmark Mode Cnt Score Error
Units
KafkaBenchmark.testFinalSerializer thrpt 1000 9378.179 ± 26.059
ops/s
KafkaBenchmark.testFinalSerializerNoFlush thrpt 1000 1283796.450 ± 4976.711
ops/s
KafkaBenchmark.testSerializer thrpt 1000 9325.273 ± 26.581
ops/s
KafkaBenchmark.testSerializerNoFlush thrpt 1000 1289296.549 ± 5127.774
ops/s
The performance difference we are seeing is very negligible at best. We have
run this across a few machines (1 macbook, 1 cisco blade server, 1 nutanix vm)
within our company and get similar results between final and non-final. (we
actually had one result come in from the linux vm running on our nutanix
clusters where the non-final was negligible faster, we repeated and it reversed
to have the other negligible faster, but it does show that this seems to be
negligible).
We have run on all the machines using the latest Kakfa 0.10.1.0 version, on JDK
1.8.0_112, VM 25.112-b16 and kafka setup locally (as per we understand you have
done), the macbook was on El Capitan, and the cisco blade and nutanix vm are
running RHEL7.
The above stats copied are from running in particular on a laptop (but are
inline with what we've seen also in our server environment) just easier to copy
from as our server environments are protected.
MacBook Pro (Retina, 15-inch, Mid 2015)
2.2 GHz Intel Core i7
16 GB 1600 MHz DDR3
This is what we have come to expect, essentially making a class final doesn't
give as much a perfomance boost as people come to think, as the modern jvm
compilers like hotspot (there is another commercial one which I'm sure we all
know of ;) but as its propriety/commercial shall avoid it for this discussion
), they really do a lot of magic under the hood for us.
Whilst this article (by Brian Goetz - his credentials kinda speak for them
selves) from way back when is very dated and now not relevant in regards to
precise jvm internals as a lot has moved on.
http://www.ibm.com/developerworks/java/library/j-jtp1029/index.html
There is one core take away i think is important, and is more important when
making a decision to use final or not.
"
final classes and methods can be a significant inconvenience when programming
-- they limit your options for reusing existing code and extending the
functionality of existing classes. While sometimes a class is made final for a
good reason, such as to enforce immutability, the benefits of using final
should outweigh the inconvenience. Performance enhancement is almost always a
bad reason to compromise good object-oriented design principles, and when the
performance enhancement is small or nonexistent, this is a bad trade-off indeed.
"
This is a change to API level, then i think really this should need a KIP, and
no doubt some further tests and arguments on a KIP discussion for the pros and
con's.
Its worth noting also very recently the ProducerRecord and ConsumerRecord, for
extensibility reasons were made non-final, if you take the current master.
was (Author: michael.andre.pearce):
Hi Matthias,
Thanks for putting together some initial tests.
When we took your test and ran it this evening (with the same parameters) we
get:
# Run complete. Total time: 01:40:11
Benchmark Mode Cnt Score Error
Units
KafkaBenchmark.testFinalSerializer thrpt 1000 9378.179 ± 26.059
ops/s
KafkaBenchmark.testFinalSerializerNoFlush thrpt 1000 1283796.450 ± 4976.711
ops/s
KafkaBenchmark.testSerializer thrpt 1000 9325.273 ± 26.581
ops/s
KafkaBenchmark.testSerializerNoFlush thrpt 1000 1289296.549 ± 5127.774
ops/s
The performance difference we are seeing is very negligible at best. We have
run this across a few machines (1 macbook, 1 cisco blade server, 1 nutanix vm)
within our company and get similar results between final and non-final. (we
actually had one result come in from the linux vm running on our nutanix
clusters where the non-final was negligible faster, we repeated and it reversed
to have the other negligible faster, but it does show that this seems to be
negligible).
We have run on all the machines using the latest Kakfa 0.10.1.0 version, on JDK
1.8.0_112, VM 25.112-b16 and kafka setup locally (as per we understand you have
done), the macbook was on El Capitan, and the cisco blade and nutanix vm are
running RHEL7.
The above stats copied are from running in particular on a laptop (but are
inline with what we've seen also in our server environment) just easier to copy
from as our server environments are protected.
MacBook Pro (Retina, 15-inch, Mid 2015)
2.2 GHz Intel Core i7
16 GB 1600 MHz DDR3
This is what we have come to expect, essentially making a class final doesn't
give as much a perfomance boost as people come to think, as the modern jvm
compilers like hotspot (there is another commercial one which I'm sure we all
know of ;) but as its propriety/commercial shall avoid it for this discussion
), they really do a lot of magic under the hood for us.
Whilst this article (by Brian Goetz - his credentials kinda speak for them
selves) from way back when is very dated and now not relevant in regards to
precise jvm internals as a lot has moved on.
http://www.ibm.com/developerworks/java/library/j-jtp1029/index.html
There is one core take away i think is important, and is more important when
making a decision to use final or not.
"
final classes and methods can be a significant inconvenience when programming
-- they limit your options for reusing existing code and extending the
functionality of existing classes. While sometimes a class is made final for a
good reason, such as to enforce immutability, the benefits of using final
should outweigh the inconvenience. Performance enhancement is almost always a
bad reason to compromise good object-oriented design principles, and when the
performance enhancement is small or nonexistent, this is a bad trade-off indeed.
"
As stated, this is a change to API level, then i think really this should need
a KIP, and no doubt some further tests and arguments on a KIP discussion for
the pros and con's.
Its worth noting also very recently the ProducerRecord and ConsumerRecord, for
extensibility reasons were made non-final, if you take the current master.
> Make serializer classes final
> -----------------------------
>
> Key: KAFKA-4424
> URL: https://issues.apache.org/jira/browse/KAFKA-4424
> Project: Kafka
> Issue Type: Improvement
> Components: clients
> Reporter: Matthias Bechtold
> Priority: Minor
>
> Implementations of simple serializers / deserializers should be final to
> prevent JVM method call overhead.
> See also:
> https://wiki.openjdk.java.net/display/HotSpot/VirtualCalls
> This breaks the API slightly, inheritors must change to generic interfaces
> Serializer / Deserializer. But architecture-wise final serialization classes
> make the most sense to me.
> So what do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
