vcs icon indicating copy to clipboard operation
vcs copied to clipboard

performance crashes with multiple calls of createisofill

Open chaosphere2112 opened this issue 8 years ago • 8 comments

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: https://github.com/UV-CDAT/uvcdat/issues/2135

chaosphere2112 avatar Nov 22 '16 23:11 chaosphere2112

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

doutriaux1 avatar Apr 09 '19 21:04 doutriaux1

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 avatar May 01 '19 05:05 lee1043

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.

lee1043 avatar May 01 '19 06:05 lee1043

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

doutriaux1 avatar May 01 '19 12:05 doutriaux1

@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

lee1043 avatar May 01 '19 21:05 lee1043

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

doutriaux1 avatar May 01 '19 21:05 doutriaux1

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

lee1043 avatar May 01 '19 21:05 lee1043

ok thanks @lee1043

doutriaux1 avatar May 01 '19 21:05 doutriaux1