-
Notifications
You must be signed in to change notification settings - Fork 85
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
Performance improvements 🚀 #488
Comments
Copying from Zulip:
comment by @mfsch |
That is something we have in mind. In the past we had considered |
Related to this, I found another potential bottleneck: segments() function for chains is slower by about a factor of 6 than the "manual" version with StaticArrays:
|
Thanks we are in the process of rewriting some internals in terms of tuples
and static vectors. Also adding more threads to speed things up.
If you have performance suggestions please submit PRs in places you already
have working code.
Em sex., 7 de jul. de 2023 14:48, Jonas ***@***.***> escreveu:
… Related to this, I found another potential bottleneck: segments() function
for chains is slower by about a factor of 6 than the "manual" version with
StaticArrays:
This small change had an improvement from 30 to 5 seconds in my case:
# @views for seg in segments(chain)
@views for (p1, p2) in zip(verts[1:n-1], verts[2:n])
seg = Segment(SA[p1, p2])
.... do stuff ....
end
—
Reply to this email directly, view it on GitHub
<#488 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZQW3K4V47AS35HIUA2NDTXPBDW5ANCNFSM6AAAAAAZYOI6CI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Switching |
Another point of performance improvement might be the boundingbox implementations:
This isn't really a priority as it is still fast, but could be a problem when running in a tight loop. |
Fully agree with all comments raised. We will be working on these internal
improvements soon as we are using the code for some agriculture
applications that are demanding more performance.
Em sex., 7 de jul. de 2023 16:14, Jonas ***@***.***> escreveu:
… Another point of performance improvement might be boundingbox
implementations:
These have a lot of allocations, which shouldn't be necessary for any
boundingbox calculation.
E.g. for this shape it's over 17kb of RAM
julia> poly
2 GeometrySet{2,Float64}
└─PolyArea(50-Ring)
└─PolyArea(356-Ring, 302-Ring)
julia> @time boundingbox(poly)
0.000021 seconds (21 allocations: 17.172 KiB)
Box{2, Float64}(Point(0.604086399, -13.3619730947), Point(149.4063610679, 13.8699076501))
This isn't really a priority as it is still fast, but could be a problem
when running in a tight loop.
—
Reply to this email directly, view it on GitHub
<#488 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZQW3KBKN6OMNPMLFI7HULXPBNYXANCNFSM6AAAAAAZYOI6CI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
@BloodWorkXGaming regarding the boundingbox allocations, did you identify the harmful lines? Feel free to submit PRs for review. If it is also related to the current internal representation of vertices in Polytope types, we will fix it in a more systematic way. |
Ye I found some harmful lines, it is rather related to the |
Update: we already implemented a series of changes to the vertices representation inside Polytope geometries. They are NTuple of Point now, which means, more compile-time optimizations. |
Update: refactored boundingbox and hull methods to allocate zero memory whenever possible. @BloodWorkXGaming all cases covered now from your previous PR. |
Thanks! Sorry for not refactoring the PR, was very low on time the past weeks |
Update: pointwise transforms no longer allocate intermediate vectors. Rotate, Translate and Stretch are examples. |
We need to improve the performance of the |
The new |
This issue tracks our efforts to improve the performance of different algorithms and data structures implemented in the project. The public API is stabilizing and there is only one major breaking change planned before a possible v1.0.
Given the solid design that separates user-facing functions from internals, we can easily refactor the code without breaking code downstream. We kindly ask the community to add comments here whenever they encounter a performance problem.
The text was updated successfully, but these errors were encountered: