-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Back to union storage #49
Conversation
Codecov Report
@@ Coverage Diff @@
## master #49 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 4 3 -1
Lines 360 249 -111
==========================================
- Hits 360 249 -111
|
@Krastanov, I know you have some code relying on SumTypes.jl for performance referenced in #28. Could I ask you to test out this PR and see if it causes any performance regressions (or improvements!) for you? |
Yes, I should be able to do so today or tomorrow. |
The only interesting benchmarks I have are with
Tested on:
If you want to double check things for yourself, these are the benchmarks that depend on sumtypes: |
Well that’s quite encouraging news! I guess julia’s handling of enclosed unions here is a bit smarter than what I was doing and enabled some speedups. |
This undoes the major overhaul of version 0.4 where we were doing computed storage. With this change, a bunch of things get a lot simpler, and we don't need to carry around extra parameters in the sum type.
While the computed storage did benefit some situations, julia's
Union
is also quite good. For allisbits
data it should have the same performance profile as before, but for non-isbits
data, there are some tradeoffs as to what ends up heap allocated and what doesn't, and I think thatUnion
actually does a better job when you're modifying and interacting with the data since there's usually fewer pointers involved.Fixes #30