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

performance crashes with multiple calls of createisofill #41

Open
chaosphere2112 opened this issue Nov 22, 2016 · 8 comments
Open

performance crashes with multiple calls of createisofill #41

chaosphere2112 opened this issue Nov 22, 2016 · 8 comments
Assignees
Labels
enhancement Needs Investigation Issues that require more probing to verify
Milestone

Comments

@chaosphere2112
Copy link
Contributor

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

@doutriaux1 doutriaux1 modified the milestone: 3.0 May 5, 2017
@doutriaux1 doutriaux1 modified the milestones: 3.0, post 3.0 Mar 29, 2018
@doutriaux1 doutriaux1 modified the milestones: 8.1, 8.2 Mar 27, 2019
@doutriaux1 doutriaux1 reopened this Apr 9, 2019
@doutriaux1 doutriaux1 modified the milestones: 8.2, Not Next Apr 9, 2019
@doutriaux1
Copy link
Contributor

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...

@lee1043
Copy link
Contributor

lee1043 commented May 1, 2019

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?

@lee1043
Copy link
Contributor

lee1043 commented May 1, 2019

Slow down appears when I re-create identical gm for new canvas, even after using removeobject(gm). Revised my code to create canvas and gm only at the beginning and reuse it for the production of multiple images, which solved the slow down issue.

@doutriaux1
Copy link
Contributor

@lee1043 yes you should create only one gm and reuse as much as possible. I have a test with removeobject(gm) for each gm, could you send me a copy of the script you used that was leading to a slow down. I would like to inspect it. This issue makes me think we should create a VCS best practices notebook.

@scottwittenburg scottwittenburg added the Needs Investigation Issues that require more probing to verify label May 1, 2019
@lee1043
Copy link
Contributor

lee1043 commented May 1, 2019

@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

@doutriaux1
Copy link
Contributor

thx @lee1043 I'm just curious about what you meant by still slowing down even after using removeobject

@lee1043
Copy link
Contributor

lee1043 commented May 1, 2019

@doutriaux1 so when you see one of my attached marked as "Old", you will see there is the part I was using canvas.removeobject(gm) in hope that would prevent slowing down. But it didn't solve it.

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.

@doutriaux1
Copy link
Contributor

ok thanks @lee1043

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Needs Investigation Issues that require more probing to verify
Projects
None yet
Development

No branches or pull requests

4 participants