Optimize qualified- / simple- ident? / keyword? / symbol?
There are some optimizations that we can make for the simple-ident?, qualified-ident?, simple-symbol?, qualified-symbol?, simple-keyword?, and qualified-keyword? functions.
Two separate optimization can be done.
In places where boolean is used (the qualified- fns), we can instead use some? for a faster implementation:
can be converted to simply
Focusing on just V8 for now, for
and subtracting out the baseline cost for
this yields a speedup of 1.74.
Since we know that we are dealing with keywords or symbols when applying namespace, we can furthermore use (.-ns x).
Alone this gives a speedup of 2.21 and when combined with the previous optimization as
we see a combined speedup approaching infinity (the operation effectively becomes free, taking the same time as the baseline).
Note that we could perhaps use predicate-induced type inference along with a new macro for namespace that emits .-ns instead, but CLJS-2866 currently hinges on looking at the test in an if, while expressions like the above cause optimized js* output with short-circuiting &&.
These optimizations would be good because these functions are often used in spec-based generative code testing where performance can be an issue.
We have test coverage for these functions in cljs.predicates-test.
and here is what we get with the revisions
(The compactness of this revised implementation means that it might be further inlinable via Closure for more speedups for whole-program optimization.)
My recommendation would be to wait and see if the other patches land, and if so, perhaps produce a simpler patch for this ticket that simply employs some? where appropriate.
Using some? as described in the ticket still seems relevant, as it enables && and elimination of unchecked ifs:
But, we don't need to use .-ns if we the other tickets in place.
With the addition of the above two tickets and CLJS-3133, simple-keyword? produces the exact same code without having to modify it:
And qualified-keyword? is close:
Predicate-induced type information flowing rightwards though and:
namespace and name intrinsics: