-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Address message aggregation overhead #203
Address message aggregation overhead #203
Conversation
It appears that the defective equals was already partially addressed in #194 but hasn't been released yet. The changes here are still necessary though:
However, the improvement we see after deploying this PR cannot be solely attributed to it and will be partially because of #194 |
I can confirm that the majority of the improvement we see is explained by the changes already made in #194 - it would be great if that could be released and pushed out to users. It's not critical to merge the changes made here, though I do still consider them beneficial. |
…d from equals, implement comparable to better handle collisions in map
01650c1
to
6674963
Compare
I created a very simple benchmark here to demonstrate the benefits of this change. The benchmark aggregates numeric messages using 4 benchmark threads, contending on an aggregator with 4 shards, measuring aggregation throughput at saturation. Increasing the number of shards doesn’t appear to change much in this set up, but may well do in highly concurrent environments. The benchmark is parameterised:
These values may look silly, but hash collisions are a fact of life with polynomial hash codes, even if contrived cases look... contrived. Running on the released 4.1.0 (make sure to clear out your .m2 cache before building to make sure it is downloaded from Maven Central though because the project doesn't use a SNAPSHOT version), when there are hash collisions, the throughput roughly halves:
On this branch, the throughput still degrades under collisions, but is improved in both cases
However, the case with collisions here isn’t pathological enough to cause degradation to |
…rable contract, add test to verify expected aggregation behaviour
d4971de
to
46ffe13
Compare
… to delete when increasing the language level
46ffe13
to
c7cf1cb
Compare
if (MAP_PUT_IF_ABSENT != null) { | ||
try { | ||
return (Message) (Object) MAP_PUT_IF_ABSENT.invokeExact(map, (Object) message, (Object) message); | ||
} catch (Throwable ignore) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What kind of exceptions can be expected here? Not propagating exceptions further means if this code breaks, it will break silently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No exception can be thrown here, it's just necessary to keep the compiler happy.
b61b169
to
e687607
Compare
…st, remove wildcard imports
e687607
to
9238fbe
Compare
Hi @vickenty - I wonder, are there any fundamental issues left for this PR to be resolved? |
We frequently see high overhead in message aggregation:
This PR consists of 3 parts:
Map.putIfAbsent
to avoid doubling the work done inMap.get
thenMap.put
(note the almost identical stack traces next to eachother). This has to be done viaMethodHandle
s but this can be greatly simplified when JDK7 support is dropped.Message
for better hashing (note theTreeMap
frames belowHashMap
which indicate hash collisions):hashCode
to avoid collisions in more casesArrays.hashCode
instead ofObjects.hash
for the tags because the latter triggers an IDE warning for ambiguous varargs parametersdone
field fromequals
which can lead to memory leaks if the value changes after inserting a key into the mapequals
when compared withthis
Comparable
for better degradation when has collisions do occurEnumMap
and make it static since it can be. The profile doesn't justify the change and I can drop the commit, but it's a generally worthwhile change.