Another big improvement to dynamic property access: Fix dynamic dispatch perf #36
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sacha0
reviewed
Jan 24, 2025
Comment on lines
+15
to
+20
| # OPTIMIZATION: Annoyingly julia dispatches on a *Type Constructor* are very expensive. | ||
| # So if you ever have a type unstable field access on a Blob, we will not know the type of | ||
| # the child Blob we will return, meaning a dynamic dispatch. Dispatching on Blob{FT}(...) | ||
| # for an unknown FT is very expensive. So instead, we dispatch to this function, which will | ||
| # be cheap because it has only one method. Then this function calls the constructor. | ||
| # This is a silly hack. :') |
There was a problem hiding this comment.
Love this comment, and looking forward to the pitfall going away! ❤️
NHDaly
force-pushed
the
nhd-getindex-dynamic-dispatch
branch
from
a55fc8d to
5aeb506
Compare
…tch perf
There's a known issue with dynamic dispatch (Thanks to Cody to pointing
this out) where it's super slow if you dispatch on a type / constructor.
Our code had a dispatch on Blob{FT} with an unknown FT in the case of a
dynamic field access. That was causing very slow performance.
By changing this to a helper function (make_blob), we do a performant
dispatch, dramatically improving perf.
Now, dynamic field access on a Blob has the ~same~ even better
performance as dynamic field access on a regular julia object! :)
```julia
julia> @Btime getproperty($(foo), $(:y))
19.057 ns (0 allocations: 0 bytes)
Blob{Float32}(Ptr{Nothing} @0x000000016fe73d90, 8, 12)
julia> @Btime getproperty($(Foo(1,2)), $(:y))
25.477 ns (2 allocations: 48 bytes)
2.0f0
```
NHDaly
force-pushed
the
nhd-getindex-dynamic-dispatch
branch
from
5aeb506 to
2e18db7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
There's a known issue with dynamic dispatch (Thanks to @topolarity to pointing this out) where it's super slow if you dispatch on a type / constructor.
Our code had a dispatch on Blob{FT} with an unknown FT in the case of a dynamic field access. That was causing very slow performance.
By changing this to a helper function (make_blob), we do a performant dispatch, dramatically improving perf.
Now, dynamic field access on a Blob has the
sameeven better performance as dynamic field access on a regular julia object! :)Before:
After:
Follow up to #35.