-
Notifications
You must be signed in to change notification settings - Fork 9
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
Reduction of Allocations -> make FerriteViz go vroom #66
Comments
We should also propagete function barriers and try to make a non-allocating version of e.g. |
TODO: We also need to investigate further the tradeoff between allocating extra arrays and maintaining performant cache access patterns. |
after #70 and MakieOrg/Makie.jl#2874 there isn't anything further to optimize if we don't have custom shaders Its a little bit tricky with MakieOrg/Makie.jl#2874 because this only dispatches on |
I also think that the remaining "performance issue" should be fixed in Makie itself, so everyone can benefit from it. However, for the surface plots I think the speed is fine enough for now, even for large plots. The other major bottleneck for "time to first plot" is Ferrite-FEM/Ferrite.jl#617 , which should be fixed in Ferrite, such that also everyone benefits here. |
Yes but my question is how we can forward the data_limits dispatches that I'm trying to add in Makie. In Makie I can only dispatch on the type of the basic mesh recipe |
You mean e.g. for scatter? Or am I misunderstanding that this line https://github.com/Ferrite-FEM/FerriteViz.jl/blob/master/src/makieplotting.jl#L314 reaches the data_limits dispatch? |
No it doesnt, since |
I think this can be closed? |
Not sure. I think we should add some kind of benchmark here to monitor perf before marking this as resolved. What do you think? |
With #63 we exploit something conceptually, however, the current implementation allocates rather much, because we run into
https://github.com/MakieOrg/Makie.jl/blob/adc9d9ae3523f746f9c32652c833a59bfc0167b2/src/conversions.jl#L581-L595
by e.g.
FerriteViz.jl/src/makieplotting.jl
Line 95 in 59285b4
where instead we could directly provide a
GLNormalMesh
which shouldn't allocate further according to Simon. If that's the case it is a bug in Makie and we could circumvent it by directly overloading recipe internals, such asdraw_atomic
. Besides that we could directly useMakie.Buffer
to construct theGLNormalMesh
in the spirit of https://docs.makie.org/stable/examples/plotting_functions/mesh/index.html#using_geometrybasicsmesh_and_buffersampler_typeThe text was updated successfully, but these errors were encountered: