Any.== slowed down by Panic.catch 2x times

[JaroslavTulach]

I have just been verifying the effect of #5845 on performance of sieve.enso and via VisualVM Polyglot Sampler I can see that an enormous time is being spent on line 31 comparing == 0 and subsequently catching panics. Single round of the benchmark takes:

Hundred thousand prime numbers in 895 ms. Last one is 1299709

By changing the Enso standard library to:

diff --git distribution/lib/Standard/Base/0.0.0-dev/src/Any.enso distribution/lib/Standard/Base/0.0.0-dev/src/Any.enso
index 565b64adcb..7181423508 100644
--- distribution/lib/Standard/Base/0.0.0-dev/src/Any.enso
+++ distribution/lib/Standard/Base/0.0.0-dev/src/Any.enso
@@ -108,8 +108,8 @@ type Any
     == self that =
         # If there is No_Such_Conversion, then `self` and `that` are probably
         # host or polyglot values, so we just compare them with the default comparator.
-        eq_self = Panic.catch No_Such_Conversion (Comparable.from self) _-> Default_Comparator
-        eq_that = Panic.catch No_Such_Conversion (Comparable.from that) _-> Default_Comparator
+        eq_self = Comparable.from self
+        eq_that = Comparable.from that
         similar_type = Meta.is_same_object eq_self eq_that
         case similar_type of
             False -> False

I am able to get to better numbers. Single round of the benchmark goes down to:

Hundred thousand prime numbers in 403 ms. Last one is 1299709

e.g. the benchmark gets twice as fast by eliminating Panic.catch call.

[hubertp]

Isn't this related to the whole if/then/else slowdown. Seems like thunk execution is really the root of all evil.

[JaroslavTulach]

Isn't this related to the whole if/then/else slowdown. Seems like thunk execution is really the root of all evil.

Yes, the if/then/else handling may be the cause. I did some investigation #5709 (comment) and yes, there is a spurious OptimizedCallTarget.callBoundary - it shouldn't be there. However I am not sure how to get rid of it.

Anyway the current Any.== logic is complex and simplifying it for simple cases is also desirable.

[enso-bot]

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

Progress: - Any.== integrated: #6184

• further improvements for Any.==: Any.== slowed down by gigantic EqualsNode specializations #6191
• fixes to 4bc2353
• Planning engine tasks with James, Sylwia
• Triage: Add syntax for specifying the return type on the same line as function arguments (parser part) #6166 - sent towards Kaz
• suspended atom fields cleanup:
• cb89ab6
• infinite list test: d76cb6e
• discussing Truffle topics with Štěpán Šindelář: If cascades 5x slower than case-of due to limit of recursive inlining #5709 (comment) It should be finished by 2023-04-04.

Next Day: Lazy atom fields