-
Notifications
You must be signed in to change notification settings - Fork 13
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 crashes with multiple calls of createisofill #41
Comments
when creating a graphic method, we could see if another one as exactly the same attributes and in this case simplky create a pointer to it. The downside is that everytime we edit an attribute we need to look at all existing graphic methods and see if the newly changed method is a duplicate of another one... |
I am revisiting this issue. @doutriaux1 so do you recommend to create a canvas and a graphic method only one time at the beginning and reuse them over and over when generating multiple images? |
Slow down appears when I re-create identical gm for new canvas, even after using |
@lee1043 yes you should create only one gm and reuse as much as possible. I have a test with |
@doutriaux1 thanks for information. I revised my code accordingly, so it is not showing slowdown issue anymore. I was thinking to make my code as toy version for your investigation, but as it was already revised to work properly, I am not sure we really want to spend time on that specific code. My script has complex dependencies though, so if you really want to dive in I may able to try to make it simpler. For the first look, I am attaching old (with slow down issue) and revised (issue gone) codes here. Old: multi_panel_plot_slowdown.py.txt Revised: multi_panel_plot.py.txt |
thx @lee1043 I'm just curious about what you meant by still slowing down even after using removeobject |
@doutriaux1 so when you see one of my attached marked as "Old", you will see there is the part I was using So the way I solved was like in the other attached marked as "Revised", which creates canvas and gm before start looping for individual plots and re-use them in the loop, following your advice. |
ok thanks @lee1043 |
I am repeatedly (17 times) calling a function which generates a set of four plots with VCS. They should all take about the same time. With normal use of VCS, they don't. Each is slower than the one before, and you get an overall slowdown of well over an order of magnitude - enough to make VCS almost unusable.
I narrowed the problem down to vcs.elements['isofill']. Each time my function is called another 10 or so names get added to this list. The running time of canvas.plot is superlinear in the length of vcs.elements['isofill'].
As a workaround, I saved a copy of an early form of vcs.elements, and restored it (other than vcs.elements['display']) frequently. This completely eliminated the performance problem, and my test problem's running time went from 3 1/2 hours to 16 minutes.
It seems to me that something in VCS does something very expensive with everything in vcs.elements['isofill']. There may be design issues - why does everything have to be saved forever? - but that is beyond my competence to judge.
Migrated from: CDAT/cdat#2135
The text was updated successfully, but these errors were encountered: