|
|
|
|
|
by hyperpape
3277 days ago
|
|
The issue is that with the string/regex issue, there's a good reason that the string operation should be faster. Maybe a "sufficiently smart compiler" could optimize it in some cases of static regexes, but it's at least complicated. In cases where the regex is dynamically determined, even the sufficiently smart compiler probably can't optimize away the regex. In contrast, the case in this article seems like table stakes for an optimizing compiler. It's just not eliminating common subexpressions. There's no reason to contort your code around something that should automatically happen. |
|
start_with: 5703143.1 i/s regex: 2821224.4 i/s - 2.02x slower
That aside:
> There's no reason to contort your code around something that should automatically happen.
Absolutely, but it's a question of style at that point. "Contorting your code" suggests using a less desirable style/syntax for some gain, and I'd agree would be premature optimisation. If you're just making a choice between two styles that you consider to be pretty much equal then it's just pragmatic.
edit: Forgot to add, yes, I agree that this should happen automatically in the compiler :)