quickfixj icon indicating copy to clipboard operation
quickfixj copied to clipboard

Remove "if else" statements which is slower by nearly 7 times compared to HashMaps in generated MessageCracker class

Open busy-spin opened this issue 3 years ago • 1 comments
trafficstars

Describe the bug MessageCracker generated class contains a lengthy if else statement to resolve the method call for the respective message type. Current logic is about 7 times slower than using HashMap key'd by message type and value as the method reference.

I wrote a new MessageCracker.xsl which use the HashMap to resolve the method respective to message type.

Following is the JMH benchmarking results.

Before:

benchmarkCrackingGenerated - use the current MessageCracker.xls generated class benchmarkCrackingWithHashMap use custom MessageCracker class which use HashMaps to resolve methods

Benchmark Mode Cnt Score Error Units MessageCrackerBenchmark.benchmarkCrackingGenerated thrpt 5 10923194.106 ± 2861197.934 ops/s MessageCrackerBenchmark.benchmarkCrackingWithHashMap thrpt 5 69723897.515 ± 3242125.694 ops/s

After:

benchmarkCrackingGenerated - use the new MessageCracker.xls generated class benchmarkCrackingWithHashMap use custom MessageCracker class which use HashMaps to resolve methods

Benchmark Mode Cnt Score Error Units MessageCrackerBenchmark.benchmarkCrackingGenerated thrpt 5 71897498.754 ± 19147681.365 ops/s MessageCrackerBenchmark.benchmarkCrackingWithHashMap thrpt 5 72165054.010 ± 4905711.116 ops/s

To Reproduce Run my JMH benchmark code in my forked repo for QFJ

Before

Before Code Benchmark

After

After Code Benchmark

Expected behavior N/A

system information:

  • OS: [Windows11]
  • Java version [JDK8]
  • QFJ Version [3.0.0-SNAPSHOT]

Additional context N/A

busy-spin avatar Nov 20 '22 18:11 busy-spin

I made a PR for this , https://github.com/quickfix-j/quickfixj/pull/578

busy-spin avatar Nov 20 '22 18:11 busy-spin