-
Notifications
You must be signed in to change notification settings - Fork 36
Various optimizations #68
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
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #68 +/- ##
==========================================
- Coverage 93.17% 89.90% -3.27%
==========================================
Files 2 2
Lines 205 208 +3
==========================================
- Hits 191 187 -4
- Misses 14 21 +7
☔ View full report in Codecov by Sentry. |
I've pushed some changes based on your comments. |
b83c033
to
ea835d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
to avoid the extra type parameters, I've changed the representation of the tree to use Union{Nothing,KDNode} (where KDNode is the new name for KDInternalNode.) The performance is the same as before.
That is, you see the same performance improvements as in the initial version of the PR? Good if we can avoid deeply nested types.
Indeed. It was relative to the previous version of this PR which is much faster than current master. |
This avoids a lot of dynamic dispatch by removing abstract type in the fields by making
KDInternalNode
andKDTree
parametric on the node types and by avoidingAbstractArray
as fields. At least for now, it should be fine to requireMatrix
andVector
either directly of via conversion. Some timings.Current:
New:
It might still be possible to improve the speed a bit. E.g. some of the nested loops are in the wrong order but profiling suggests that most of the time in
loess
is spent withinqr
and forpredict
it's spent on allocating the arrays for storing the results so there shouldn't be that much performance left on the table.Closes #47 and #51. Supersedes #53
Update: to avoid the extra type parameters, I've changed the representation of the tree to use
Union{Nothing,KDNode}
(whereKDNode
is the new name forKDInternalNode
.) The performance is the same as before.