-
Notifications
You must be signed in to change notification settings - Fork 68
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 #2135
Comments
Everything gets saved forever because people can plot isofills just using the name of the graphics method:
If people stash the name of a graphics method, they'll still be able to use it later unless they actively prevent themselves from doing so. That said, I just ran this:
And got these results (trimmed everything that used less than a quarter of a second):
The offending function is |
@painter1 @chaosphere2112 Why would one create a new graphics method for each plot? In this case one would expect things to accumulate. Is this what is happening in Jeff's plot? Jeff, can you post the relevant function you are calling? |
I ran my code three times for different timing purposes. The first is to demonstrate the problem with only two plots. This is logically the minimum number of plots to show a slowdown as you make more plots. The time for all calls of canvas.plot(): The second run was the same, except with a call of canvas.clean_auto_generated_objects() before making a plot: The third run was of my whole suite of 17 plot sets, 4 plots per set. Now again, I'm not calling clean_auto_generated_objects() or forcibly resetting vcs.elements. |
I gave up on calling clean_auto_generated_objects(). It doesn't work. The problem occurs if you use EzTemplate.Multi (in vcsaddons). The templates this object makes contain things (like text orientation) with names beginning with '__', so they get cleaned as the should be. But the templates themselves don't have such names, so they don't get cleaned. If you change the names so that they get cleaned out, then you run into the problem that the Multi object keeps its own list. You have to keep track of Multi objects and call their clean methods too. I fear that if I were to make all these changes, I would soon discover another way in which clean_auto_generated_objects() doesn't work. It's simpler, and in practice much more reliable, to save and restore vcs.elements. |
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.
The text was updated successfully, but these errors were encountered: