Any.== slowed down by gigantic EqualsNode specializations

[JaroslavTulach]

#5898 investigation brought down the sieve benchmark to 518ms on my computer. While continuing investigations I found a way to get down to 333ms. It is just necessary to productize my prototype...

• EqualsNode contains gigantic amount of @Specialization which leads to (possibly) too huge execute method in EqualsNodeGen. Such a huge method may overload the compiler thresholds and disable some optimization. @steve-s suggested to split the node into few smaller ones
• We should optimize for most common cases - e.g. first of all check for primitive type comparisons and only then move to other builtins and/or to custom comparators
• Current Any.== implementation checks comparators first - given most of our common cases don't have special comparator this is a waste of CPU

Remove the Enso Any.== code. Split the logic into multiple nodes. Revert the checks to optimize for most common situations. CCing @Akirathan

[Akirathan]

I agree. Reducing Any.== to just a builtin method, without the overhead of some Enso code wrapper seems like a good idea, and will be easily implemented once we have #5740. Moreover, optimizing for primitive value comparison is indeed a good idea.

[Akirathan]

EqualsNode contains gigantic amount of @specialization which leads to (possibly) too huge execute method in EqualsNodeGen. Such a huge method may overload the compiler thresholds and disable some optimization.

Right. Once there are many specializations instantiated, the compilation might get tricky. Also, it is a problem for the interpreter.

[enso-bot]

Jaroslav Tulach reports a new STANDUP for yesterday (2023-04-17):

Progress: - EqualsNode got merged in: #6280

• Bugfix NPE in IGV: Avoid NullPointerException in --dumpGraphs & test & docs #6304
• test for @BuildMethod with/without VirtualFrame It should be finished by 2023-04-17.

Next Day: Planning new interation. Fixing.