Rendering slowdown

[glutamate]

In bayeshive, if you alternate editing and rendering a document containing a plot several times, the document takes longer and longer to render, up to 10 secs for the 3rd time of a document with a single plot with ~500 points. Garbage collection problem?

[ian-ross]

Almost certainly stuff not getting cleaned up, probably within calls to D3. I'll fix it...

On 19 April 2013 18:22, Tom Nielsen notifications@github.com wrote:

In bayeshive, if you alternate editing and rendering a document containing a plot several times, the document takes longer and longer to render, up to 10 secs for the 3rd time of a document with a single plot with ~500 points. Garbage collection problem?

— Reply to this email directly or view it on GitHubhttps://github.com/glutamate/Radian/issues/8 .

Ian Ross Tel: +43(0)6804451378 ian@skybluetrades.net www.skybluetrades.net

[ian-ross]

Hi Tom,

Is this a points plot or a time series plot? I've just been playing around with some time series examples (10000 data points each), and I don't see a noticeable slowdown. But it's quite possible that I'm just not doing what you were. Are you switching between the "Edit" and "View" tabs in the main document page, or in the dashboard? (Incidentally, not that it really matters, but the autoupdate in the main document pages seems to have stopped working: I guess we don't care if we're going to edit within the dashboard.)

Can you tell me the exact sequence of actions needed to replicate this? I've messed around a bit, but I can't get it to behave the way you describe.

Cheers,

Ian.

On 19 April 2013 18:28, Ian Ross ian@skybluetrades.net wrote:

Almost certainly stuff not getting cleaned up, probably within calls to D3. I'll fix it...

On 19 April 2013 18:22, Tom Nielsen notifications@github.com wrote:

In bayeshive, if you alternate editing and rendering a document containing a plot several times, the document takes longer and longer to render, up to 10 secs for the 3rd time of a document with a single plot with ~500 points. Garbage collection problem?

— Reply to this email directly or view it on GitHubhttps://github.com/glutamate/Radian/issues/8 .

Ian Ross Tel: +43(0)6804451378 ian@skybluetrades.net www.skybluetrades.net

Ian Ross Tel: +43(0)6804451378 ian@skybluetrades.net www.skybluetrades.net

[glutamate]

Yes, the doc page is on its way out so I thought it'd be ok breaking it. I am talking about in the dashboard, using the edit/view/options button group in the top right. To replicate this, it is not enough to just toggle between edit and view - you have to actually edit the document in edit mode (i.e. replace a few words) and then hit view. (you'd certainly expect a user to operate in this mode).

you will see that doing this cycle just twice or thrice, you will see the temporary notice "Typesetting" in the doc view. if you grep "dashboard.julius" for this, you will see that this indicates that the ajax response html has been received and angular is $compiling it (and presumably Radian is doing its radiating during this, because I dont see this delay when there is no plot). The call to $compile on the html is inside a $timeout with 0ms just to get the "typesetting" msg up there on the screen.

I'll email you the dataset and the document i use to get this.

On Sat, Apr 20, 2013 at 5:23 PM, Ian Ross notifications@github.com wrote:

Hi Tom,

Is this a points plot or a time series plot? I've just been playing around with some time series examples (10000 data points each), and I don't see a noticeable slowdown. But it's quite possible that I'm just not doing what you were. Are you switching between the "Edit" and "View" tabs in the main document page, or in the dashboard? (Incidentally, not that it really matters, but the autoupdate in the main document pages seems to have stopped working: I guess we don't care if we're going to edit within the dashboard.)

Can you tell me the exact sequence of actions needed to replicate this? I've messed around a bit, but I can't get it to behave the way you describe.

Cheers,

Ian.

On 19 April 2013 18:28, Ian Ross ian@skybluetrades.net wrote:

Almost certainly stuff not getting cleaned up, probably within calls to D3. I'll fix it...

On 19 April 2013 18:22, Tom Nielsen notifications@github.com wrote:

In bayeshive, if you alternate editing and rendering a document containing a plot several times, the document takes longer and longer to render, up to 10 secs for the 3rd time of a document with a single plot with ~500 points. Garbage collection problem?

— Reply to this email directly or view it on GitHub< https://github.com/glutamate/Radian/issues/8> .

Ian Ross Tel: +43(0)6804451378 ian@skybluetrades.net www.skybluetrades.net

Ian Ross Tel: +43(0)6804451378 ian@skybluetrades.net www.skybluetrades.net

— Reply to this email directly or view it on GitHubhttps://github.com/glutamate/Radian/issues/8#issuecomment-16706709 .

[ian-ross]

This turned out to be a scope management issue in dashboard.julius. The enclosing scope passed to the load_document function was being passed on to $compile, which meant that scopes created by elements inside the HTML returned from the server were just piling up (and Radian does a depth-first traversal of the scope tree for some rendering tasks, which is why it was slowing down). I think the correct approach (which I've now implemented in dashboard.julius) is to explicitly manage the lifetime of the scope passed to $compile. This is more or less what the ng-include directive does as well, and it seems to work.