If you compile fasta with Crystal 0.33.0 and run it with n=15000000, you get:
3.04 real 2.24 user 0.12 sys
If you compile it with -D disable_overflow and run it, you get:
2.19 real 1.97 user 0.13 sys
From this, it’s pretty obvious that the slowness comes from overflow checking.
@gummybears Even if you changed your code to use &+ instead of +, I’m sure you didn’t change every occurrence of + and - in the standard library. You have to change it everywhere. But that’s impossible of course.
My conclusion is one of these:
- Get used to the new performance. The old performance was fake because programs might have been wrong because of silent overflows.
- It might still be good for Crystal to provide a flag to disable overflow checking. Rust removes overflow checking when compiled in release mode. The idea is that once you make sure in development that nothing overflow, you disable the check at runtime for greater performance.
I believe doing 2 is very, very important if Crystal wants to be successful in more math-y territories, where performance is critical. Overflow? Not that critical because you usually use big numbers like Int64 or UInt64 and the numbers are bounded.
I wouldn’t do it like Rust. I would have overflow checking by default, but still provide a flag to disable it. The core team should basically revert the PR that removed -D disable_overflow. Or better put it with another name.