Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since
BUILTIN_TYPE
andRCLASS_SINGLETON_P
are both stored inRBasic.flags
, we can combine these two checks in a single bitmask.This rely on
T_ICLASS
andT_CLASS
not overlapping, and assumeklass
is always either of these types.Just combining the masks brings a small but consistent 1.08x speedup on the simple case benchmark.
But with the RB_UNLIKELY compiler hint, it's much more significant, however the singleton and enxtended cases are slowed down.
However we can assume the simple case is way more common than the other two.
And since the logic is very similar, I was able to reuse
fake_class_p
inrb_class_real
simply by ensuringT_MODULE
never hasFL_SINGLETON
set.Then, when we're calling from Ruby's
Kernel#class
method, we know for sureRBasic.klass
can't possibly be0
, so if we add a specialized function that skips the null check, we can speed the method some more:In a followup, It could be worth exploring the possibility of ensuring
T_ICLASS
always hadFL_SINGLETON
set, as it would allow reducingfake_class_p
to a single bit check. But not sure it would make much of a difference.Another thing worth exploring would be YJIT codegen.