8000 improve performance of project_line_points by SimonDanisch · Pull Request #4601 · MakieOrg/Makie.jl · GitHub
[go: up one dir, main page]

Skip to content
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

improve performance of project_line_points #4601

Merged
merged 4 commits into from
Nov 20, 2024
Merged

Conversation

SimonDanisch
Copy link
Member
x = rand(Point2f, 10^6)
f, ax, pl = lines(x);
@btime CairoMakie.project_line_points(f.scene, pl, x, :red, 1.0f0)

PR:
12.143 ms (16 allocations: 49.59 MiB)
Master:
2.643 s (86997922 allocations: 2.02 GiB)

@MakieBot
Copy link
Collaborator
MakieBot commented Nov 19, 2024

Benchmark Results

SHA: 7863f3c1dc01fbd74edeb76b06e35ec48229f519

Warning

These results are subject to substantial noise because GitHub's CI runs on shared machines that are not ideally suited for benchmarking.

GLMakie
CairoMakie
WGLMakie

Copy link
Collaborator
@ffreyer ffreyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell this just changes the generated function to a normal one, adds a couple of type annotations and an @inbounds. Should be fine

space = (plot.space[])::Symbol
model = (plot.model[])::Mat4d
# Standard transform from input space to clip space
points = Makie.apply_transform(transform_func(plot), positions, space)::typeof(positions)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not guaranteed for 2D to 3D or 3D to 2D transformations...is this type annotation necessary here? Can we specify that it will be a Vector of VecT 8000 ypes maybe?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is required right now, since somehow it doesn't get inferred... This happens because transform_func doesn't infer. not sure what to do about it, I guess we could also put it behind a function barrier and extract transform_func before this function call and pass it as an argument.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

easiest would be to put everything after this behind another function barrier, apply_transform is already the function barrier for the dynamic transform_func result, but the stuff after is not guarded without ::typeof(positions)

@jkrumbiegel
Copy link
Member

I wonder if this has badly regressed at some point because I'm pretty sure I optimized the main drawing functions at some point so they didn't unnecessarily allocate. Could we add regression tests for this stuff?

@SimonDanisch
Copy link
Member Author

Well the benchmark seems to catch this really well... This may be the pr:
#3958
Which got merged with the 20% regression we see improved here.

@SimonDanisch
Copy link
Member Author

I think it'd be nice to slowly add more benchmarks and whole flamegraphs, which should catch function regressions pretty well.

@SimonDanisch SimonDanisch merged commit 3a2cf37 into master Nov 20, 2024
20 of 21 checks passed
@SimonDanisch SimonDanisch deleted the sd/fast-cairo-lines branch November 20, 2024 16:52
@SimonDanisch
Copy link
Member Author

@asinghvi17 ah sorry, I forgot to address your comment.
Do you have time to look into it?

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

Successfully merging this pull request may close these issues.

5 participants
0