Skip to content

applyreduce has 1 allocation where sum does not #244

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

Closed
asinghvi17 opened this issue Jan 6, 2025 · 1 comment
Closed

applyreduce has 1 allocation where sum does not #244

asinghvi17 opened this issue Jan 6, 2025 · 1 comment
Assignees

Comments

@asinghvi17
Copy link
Member

using Chairmarks
import GeometryOps as GO, GeoInterface as GI


function _area(p::GI.LinearRing)
    first_point = p.geom[1]
    area = 0.0
    for next_point in view(p.geom, 2:length(p.geom))
        area += first_point[1] * next_point[2] - first_point[2] * next_point[1]
        first_point = next_point
    end
    return area
end

_area(p::GI.Polygon) = if length(p.geom) == 1
    _area(p.geom[1])
else
    _area(p.geom[1]) - sum(_area, view(p.geom, 2:length(p.geom)))
end


p = GI.Polygon([GI.LinearRing([(0, 0), (0,1), (1, 1), (1, 0), (0, 0)])])

@be GO.area($p) # ~6 ns
@be _area($p)   # ~7 ns
# These two are at least equivalent - showing that `apply` and `applyreduce` are indeed cost-free.

@be GO.area($([p, p])) # ~17 ns, 1 allocation
@be sum($_area, $([p, p])) # ~15 ns, no allocations
# So there is work to do here.

We need to isolate and remove this allocation!

@asinghvi17
Copy link
Member Author

Fixed by #305 - since we can pass the trait down the whole chain of applyreduce, we don't use trait information that the compiler may not be able to infer from the type.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants