пт, 28 авг. 2020 г. в 11:16, Alex Plehanov <plehanov.a...@gmail.com>:
> Guys, > > We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted it > locally) and got the same performance as on 2.8.1 > > IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these > hot paths, it's clear why we have performance drop here. > > IGNITE-12568 (MessageFactory refactoring) - switch/case block was > refactored to an array of message suppliers. The message factory is on the > hot path, which explains why this commit has an impact on total > performance. > I've checked JIT assembly output, done some JMH microbenchmarks, and found > that old implementation of MessageFactory.create() about 30-35% faster than > the new one. The reason - approach with switch/case can effectively inline > message creation code, but with an array of suppliers relatively heavy > "invokeinterface" cannot be skipped. I've tried to rewrite the code using > an abstract class for suppliers instead of an interface (to > replace "invokeinterface" with the "invokevirtual"), but it gives back only > 10% of method performance and in this case, code looks ugly (lambdas can't > be used). Currently, I can't find any more ways to optimize the current > approach (except return to the switch/case block). Andrey Gura, as the > author of IGNITE-12568, maybe you have some ideas about optimization? > > Perhaps we should revert IGNITE-12568, but there are some metrics already > created, which can't be rewritten using old message factory implementation > (IGNITE-12756). Guys, WDYT? > Alexey, I see that IGNITE-12756 (metrics improvements) is already released in Ignite 2.8.1 while IGNITE-12568 (message factory) is only present in Ignite 2.9. Let's revert both IGNITE-12568 and whichever new metrics created for 2.9 that depend on the new message factory to unblock the release and deal with the optimizations in 2.10?
