Performance improvements for streaming graphs

[jonnii]

There are a few problems with the streaming graphs. To start with we're redrawing the entire graph on every tick, which is unnecessary. I'm not exactly sure what the best solution to this is, but my initial thoughts are as follows.

1. Only draw a line segment once.
2. Break up each graph into multiple segments.
3. Move the graph by animating the segments (this will be a lot cheaper than redrawing I think).
4. Remove segments when they are no longer visible.
5. Have a "special" segment at the graph edge which is continually drawn on every tick, but which should be small. Once it reached a certain length reify it into a line segment and push it onto the stack to be animated.

What do you think? Does this sound reasonable? I hope that something like this will get us to 32 streams, whilst remaining smooth.

[jbrukh]

Yeah, that sounds good. Not sure on the performance of animate vs redraw -- does that introduce artificial delays for the animation?

Graphs should take advantage of the socket's batching mechanism. So, for instance, you could request 250 pps in batches of 50. That means you get a data frame every 200 ms containing 50 points -- should be more than enough time to append the points to your channel buffers and redraw. Also lowers socket overhead as right now you request 1 sample per data message.

This introduces a skip to the graph, but IMO delivering the points is more important than smoothness of the graph. You can still optimize smoothness by increasing the refresh rate (e.g. lowering batch size) and/or lowering the pps. We could then use your animation suggestion and go further with optimization.

Potentially we could correlate pps/batchSize with the number of channels.

[jonnii]

Animating should be cheap, because you're just moving a rendered graphic element. To support what I'm suggesting we'd have to use batching anyway. The problem with batching is timestamps, and changing the graph to be timestamp aware, which is fine if we do the above work.

[moscow25]

Do we really need to draw 32 graphs at once?

Your idea are all good, but at some point this borders on over-engineering. Maybe. Just a thought.

Nikolai

On Fri, May 17, 2013 at 9:01 AM, Jonathan Goldman notifications@github.comwrote:

There are a few problems with the streaming graphs. To start with we're redrawing the entire graph on every tick, which is unnecessary. I'm not exactly sure what the best solution to this is, but my initial thoughts are as follows.

1. Only draw a line segment once.
2. Break up each graph into multiple segments.
3. Move the graph by animating the segments (this will be a lot cheaper than redrawing I think).
4. Remove segments when they are no longer visible.
5. Have a "special" segment at the graph edge which is continually drawn on every tick, but which should be small. Once it reached a certain length reify it into a line segment and push it onto the stack to be animated.

What do you think? Does this sound reasonable? I hope that something like this will get us to 32 streams, whilst remaining smooth.

— Reply to this email directly or view it on GitHubhttps://github.com/jbrukh/octopus/issues/44 .

[jbrukh]

Point taken, but performance is still squirrelly on less powerful computers even for 4 or 8 graphs. These are straightforward optimizations we've provided for ahead of time.

On Fri, May 17, 2013 at 1:39 PM, Nikolai Yakovenko <notifications@github.com

wrote:

Do we really need to draw 32 graphs at once?

Your idea are all good, but at some point this borders on over-engineering. Maybe. Just a thought.

Nikolai

On Fri, May 17, 2013 at 9:01 AM, Jonathan Goldman notifications@github.comwrote:

There are a few problems with the streaming graphs. To start with we're redrawing the entire graph on every tick, which is unnecessary. I'm not exactly sure what the best solution to this is, but my initial thoughts are as follows.

1. Only draw a line segment once.
2. Break up each graph into multiple segments.
3. Move the graph by animating the segments (this will be a lot cheaper than redrawing I think).
4. Remove segments when they are no longer visible.
5. Have a "special" segment at the graph edge which is continually drawn on every tick, but which should be small. Once it reached a certain length reify it into a line segment and push it onto the stack to be animated.

What do you think? Does this sound reasonable? I hope that something like this will get us to 32 streams, whilst remaining smooth.

— Reply to this email directly or view it on GitHub< https://github.com/jbrukh/octopus/issues/44> .

— Reply to this email directly or view it on GitHubhttps://github.com/jbrukh/octopus/issues/44#issuecomment-18075563 .

[moscow25]

I agree 100%. The improvements you suggests all make a ton of sense. No argument there.

Nikolai

On Fri, May 17, 2013 at 1:46 PM, jbrukh notifications@github.com wrote:

Point taken, but performance is still squirrelly on less powerful computers even for 4 or 8 graphs. These are straightforward optimizations we've provided for ahead of time.

On Fri, May 17, 2013 at 1:39 PM, Nikolai Yakovenko < notifications@github.com

wrote:

Do we really need to draw 32 graphs at once?

Your idea are all good, but at some point this borders on over-engineering. Maybe. Just a thought.

Nikolai

On Fri, May 17, 2013 at 9:01 AM, Jonathan Goldman notifications@github.comwrote:

There are a few problems with the streaming graphs. To start with we're redrawing the entire graph on every tick, which is unnecessary. I'm not exactly sure what the best solution to this is, but my initial thoughts are as follows.

1. Only draw a line segment once.
2. Break up each graph into multiple segments.
3. Move the graph by animating the segments (this will be a lot cheaper than redrawing I think).
4. Remove segments when they are no longer visible.
5. Have a "special" segment at the graph edge which is continually drawn on every tick, but which should be small. Once it reached a certain length reify it into a line segment and push it onto the stack to be animated.

What do you think? Does this sound reasonable? I hope that something like this will get us to 32 streams, whilst remaining smooth.

— Reply to this email directly or view it on GitHub< https://github.com/jbrukh/octopus/issues/44> .

— Reply to this email directly or view it on GitHub< https://github.com/jbrukh/octopus/issues/44#issuecomment-18075563> .

— Reply to this email directly or view it on GitHubhttps://github.com/jbrukh/octopus/issues/44#issuecomment-18075943 .

[jonnii]

http://www.igvita.com/slides/2013/fluent-perfcourse.pdf

[jbrukh]

There's a link in there to the free version of that book. Very cool presentation.

On Wed, May 29, 2013 at 12:10 PM, Jonathan Goldman notifications@github.com wrote:

http://www.igvita.com/slides/2013/fluent-perfcourse.pdf

Reply to this email directly or view it on GitHub: https://github.com/jbrukh/octopus/issues/44#issuecomment-18627573