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