Optimizing Bokeh plot initialization

Meir_Tseitlin · April 16, 2018, 4:06pm

I am trying to optimize Bokeh load time when working with server and I am having few questions:

(1)

From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:

I am having “figure” command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it’s own socket traffic - which means it’s heavy. Multiplied by the amount of figures - it creates a significant overhead.
If this is true, is there a way to pass all those instructions directly to “figure” command, instead of updating them afterwards?

(2)

I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic… (it’s not a question - just an observation)

(3)

Are there any other ways to reduce the initialization overhead?

Tnx

Meir Tseitlin

Bryan · April 16, 2018, 4:55pm

Hi,

Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like

plot.title.text = "foo"

that automatically sends a "patch" message over the webscocket to reflect that single change. However, that should really only be the case be *subsequent* changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?

Thanks,

Bryan

···

On Apr 16, 2018, at 09:06, Meir Tseitlin <[email protected]> wrote:

I am trying to optimize Bokeh load time when working with server and I am having few questions:

(1)
From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:
* I am having "figure" command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it's own socket traffic - which means it's heavy. Multiplied by the amount of figures - it creates a significant overhead.
* If this is true, is there a way to pass all those instructions directly to "figure" command, instead of updating them afterwards?

(2)
I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic.... (it's not a question - just an observation)

(3)
Are there any other ways to reduce the initialization overhead?

Tnx
Meir Tseitlin

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Meir_Tseitlin · April 17, 2018, 10:52am

Well, that’s exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style plot.title.text = "foo" calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.

The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:

fig.line(
fig.legend.border_line_alpha = 0.5
fig.grid.grid_line_alpha =
fig.xaxis.axis_line_color =
fig.xaxis.formatter = FuncTickFormatter
fig.y_range.renderers.append(
fig.add_layout(Arrow(end=
fig.x_range.callback = CustomJS(

Thanks

···

On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:

Hi,

Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like
    plot.title.text = "foo"
that automatically sends a “patch” message over the webscocket to reflect that single change. However, that should really only be the case be subsequent changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?

Thanks,

Bryan

On Apr 16, 2018, at 09:06, Meir Tseitlin [email protected] wrote:

I am trying to optimize Bokeh load time when working with server and I am having few questions:

(1)

From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:

I am having “figure” command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it’s own socket traffic - which means it’s heavy. Multiplied by the amount of figures - it creates a significant overhead.

If this is true, is there a way to pass all those instructions directly to “figure” command, instead of updating them afterwards?

(2)

I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic… (it’s not a question - just an observation)

(3)

Are there any other ways to reduce the initialization overhead?

Tnx

Meir Tseitlin

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Meir_Tseitlin · April 17, 2018, 11:02am

I tried passing arguments like:
figure (… ,

legend = Legend(

location = “top_left”,

border_line_alpha = 0.5,

border_line_width = 0,

border_line_color = col,

background_fill_color = fil_col,

background_fill_alpha = 0.5,

label_text_color = text.col,

click_policy = “hide”,

))

without any success…

···

On Tuesday, April 17, 2018 at 1:52:41 PM UTC+3, Meir Tseitlin wrote:

Well, that’s exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style plot.title.text = "foo" calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.

The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:

fig.line(

fig.legend.border_line_alpha = 0.5

fig.grid.grid_line_alpha =

fig.xaxis.axis_line_color =

fig.xaxis.formatter = FuncTickFormatter

fig.y_range.renderers.append(

fig.add_layout(Arrow(end=

fig.x_range.callback = CustomJS(

Thanks

On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:
Hi,

Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like
    plot.title.text = "foo"
that automatically sends a “patch” message over the webscocket to reflect that single change. However, that should really only be the case be subsequent changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?

Thanks,

Bryan

On Apr 16, 2018, at 09:06, Meir Tseitlin [email protected] wrote:

I am trying to optimize Bokeh load time when working with server and I am having few questions:

(1)

From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:

I am having “figure” command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it’s own socket traffic - which means it’s heavy. Multiplied by the amount of figures - it creates a significant overhead.

If this is true, is there a way to pass all those instructions directly to “figure” command, instead of updating them afterwards?

(2)

I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic… (it’s not a question - just an observation)

(3)

Are there any other ways to reduce the initialization overhead?

Tnx

Meir Tseitlin

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · April 17, 2018, 2:42pm

Meir,

Well, as I said, there should the script runs on every session, to create a Document for that session. And there should oonly be one large update at the end of s script, with a completed document for the session. If that's not happening, it's worth investigating because it's not expected. But again, what would be helpful is information to reproduce: a complete script, and a description of your methodology/process that leads you to conclude that messages are being sent early (before the script finishes on each connection).

Thanks,

Bryan

···

On Apr 17, 2018, at 04:02, Meir Tseitlin <[email protected]> wrote:

I tried passing arguments like:
     figure (.... ,
            legend = Legend(
                location = "top_left",
                border_line_alpha = 0.5,
                border_line_width = 0,
                border_line_color = col,
                background_fill_color = fil_col,
                background_fill_alpha = 0.5,
                label_text_color = text.col,
                click_policy = "hide",
            ))

without any success.....

On Tuesday, April 17, 2018 at 1:52:41 PM UTC+3, Meir Tseitlin wrote:

Well, that's exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style `plot.title.text = "foo"` calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.

The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:
* fig.line(
* fig.legend.border_line_alpha = 0.5
* fig.grid.grid_line_alpha =
* fig.xaxis.axis_line_color =
* fig.xaxis.formatter = FuncTickFormatter
* fig.y_range.renderers.append(
* fig.add_layout(Arrow(end=
* fig.x_range.callback = CustomJS(

Thanks

On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:
Hi,

Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like

        plot.title.text = "foo"

that automatically sends a "patch" message over the webscocket to reflect that single change. However, that should really only be the case be *subsequent* changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?

Thanks,

Bryan

> On Apr 16, 2018, at 09:06, Meir Tseitlin <[email protected]> wrote:
>
> I am trying to optimize Bokeh load time when working with server and I am having few questions:
>
> (1)
> From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:
> * I am having "figure" command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it's own socket traffic - which means it's heavy. Multiplied by the amount of figures - it creates a significant overhead.
> * If this is true, is there a way to pass all those instructions directly to "figure" command, instead of updating them afterwards?
>
> (2)
> I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic.... (it's not a question - just an observation)
>
> (3)
> Are there any other ways to reduce the initialization overhead?
>
> Tnx
> Meir Tseitlin
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/408ad348-2757-437c-bfa6-6b18fdf003fb%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Bryan · April 17, 2018, 4:25pm

Hi,

We seem to be miscommunicating. What I am asking to know is: how are you actually certain that these extra messages are getting sent, because as I have said, there should not be any. They s hours only be one init message with a compete document. Otherwise, to be explicit: I think that is a bug. But I need your help with more information.

Bryan

···

On Apr 17, 2018, at 07:42, Bryan Van de ven <[email protected]> wrote:

Meir,

Well, as I said, there should the script runs on every session, to create a Document for that session. And there should oonly be one large update at the end of s script, with a completed document for the session. If that's not happening, it's worth investigating because it's not expected. But again, what would be helpful is information to reproduce: a complete script, and a description of your methodology/process that leads you to conclude that messages are being sent early (before the script finishes on each connection).

Thanks,

Bryan

On Apr 17, 2018, at 04:02, Meir Tseitlin <[email protected]> wrote:

I tried passing arguments like:
    figure (.... ,
           legend = Legend(
               location = "top_left",
               border_line_alpha = 0.5,
               border_line_width = 0,
               border_line_color = col,
               background_fill_color = fil_col,
               background_fill_alpha = 0.5,
               label_text_color = text.col,
               click_policy = "hide",
           ))

without any success.....

On Tuesday, April 17, 2018 at 1:52:41 PM UTC+3, Meir Tseitlin wrote:

Well, that's exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style `plot.title.text = "foo"` calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.

The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:
* fig.line(
* fig.legend.border_line_alpha = 0.5
* fig.grid.grid_line_alpha =
* fig.xaxis.axis_line_color =
* fig.xaxis.formatter = FuncTickFormatter
* fig.y_range.renderers.append(
* fig.add_layout(Arrow(end=
* fig.x_range.callback = CustomJS(

Thanks

On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:
Hi,

Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like

       plot.title.text = "foo"

that automatically sends a "patch" message over the webscocket to reflect that single change. However, that should really only be the case be *subsequent* changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?

Thanks,

Bryan

On Apr 16, 2018, at 09:06, Meir Tseitlin <[email protected]> wrote:

I am trying to optimize Bokeh load time when working with server and I am having few questions:

(1)
From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:
* I am having "figure" command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it's own socket traffic - which means it's heavy. Multiplied by the amount of figures - it creates a significant overhead.
* If this is true, is there a way to pass all those instructions directly to "figure" command, instead of updating them afterwards?

(2)
I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic.... (it's not a question - just an observation)

(3)
Are there any other ways to reduce the initialization overhead?

Tnx
Meir Tseitlin

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
To post to this group, send email to bo...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/408ad348-2757-437c-bfa6-6b18fdf003fb%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Bryan · April 17, 2018, 5:57pm

To be completely explicit, this code:

from bokeh.io import curdoc
from bokeh.plotting import figure

p = figure()
p.background_fill_alpha = 0.5

curdoc().add_root(p)

Should only make *one* big web socket message (per session) to initialize the complete document on the JS side. You seem to be saying that this is not the case. I am asking how you have determined this, so that we may try to reproduce your finding.

Thanks,

Bryan

···

On Apr 17, 2018, at 09:25, Bryan Van de ven <[email protected]> wrote:

Hi,

We seem to be miscommunicating. What I am asking to know is: how are you actually certain that these extra messages are getting sent, because as I have said, there should not be any. They s hours only be one init message with a compete document. Otherwise, to be explicit: I think that is a bug. But I need your help with more information.

Bryan

On Apr 17, 2018, at 07:42, Bryan Van de ven <[email protected]> wrote:

Meir,

Well, as I said, there should the script runs on every session, to create a Document for that session. And there should oonly be one large update at the end of s script, with a completed document for the session. If that's not happening, it's worth investigating because it's not expected. But again, what would be helpful is information to reproduce: a complete script, and a description of your methodology/process that leads you to conclude that messages are being sent early (before the script finishes on each connection).

Thanks,

Bryan

On Apr 17, 2018, at 04:02, Meir Tseitlin <[email protected]> wrote:

I tried passing arguments like:
   figure (.... ,
          legend = Legend(
              location = "top_left",
              border_line_alpha = 0.5,
              border_line_width = 0,
              border_line_color = col,
              background_fill_color = fil_col,
              background_fill_alpha = 0.5,
              label_text_color = text.col,
              click_policy = "hide",
          ))

without any success.....

On Tuesday, April 17, 2018 at 1:52:41 PM UTC+3, Meir Tseitlin wrote:

Well, that's exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style `plot.title.text = "foo"` calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.

The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:
* fig.line(
* fig.legend.border_line_alpha = 0.5
* fig.grid.grid_line_alpha =
* fig.xaxis.axis_line_color =
* fig.xaxis.formatter = FuncTickFormatter
* fig.y_range.renderers.append(
* fig.add_layout(Arrow(end=
* fig.x_range.callback = CustomJS(

Thanks

On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:
Hi,

Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like

      plot.title.text = "foo"

that automatically sends a "patch" message over the webscocket to reflect that single change. However, that should really only be the case be *subsequent* changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?

Thanks,

Bryan

On Apr 16, 2018, at 09:06, Meir Tseitlin <[email protected]> wrote:

I am trying to optimize Bokeh load time when working with server and I am having few questions:

(1)
From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:
* I am having "figure" command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it's own socket traffic - which means it's heavy. Multiplied by the amount of figures - it creates a significant overhead.
* If this is true, is there a way to pass all those instructions directly to "figure" command, instead of updating them afterwards?

(2)
I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic.... (it's not a question - just an observation)

(3)
Are there any other ways to reduce the initialization overhead?

Tnx
Meir Tseitlin

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
To post to this group, send email to bo...@continuum.io.
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/408ad348-2757-437c-bfa6-6b18fdf003fb%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Meir_Tseitlin · April 17, 2018, 6:18pm

That’s the case exactly,
Yes when I am opening a socket view in Chrome I am seeing something like this:

After initial few “heavy” transfers, there are ~100+ small updates like you see in the screenshot. (I am not sure how to copy-paste the exact log from Chrome - looks like it is not supported)

···

On Tuesday, April 17, 2018 at 8:57:17 PM UTC+3, Bryan Van de ven wrote:

To be completely explicit, this code:
    from [bokeh.io](http://bokeh.io) import curdoc

    from bokeh.plotting import figure



    p = figure()

    p.background_fill_alpha = 0.5



    curdoc().add_root(p)
Should only make one big web socket message (per session) to initialize the complete document on the JS side. You seem to be saying that this is not the case. I am asking how you have determined this, so that we may try to reproduce your finding.

Thanks,

Bryan

On Apr 17, 2018, at 09:25, Bryan Van de ven [email protected] wrote:

Hi,

We seem to be miscommunicating. What I am asking to know is: how are you actually certain that these extra messages are getting sent, because as I have said, there should not be any. They s hours only be one init message with a compete document. Otherwise, to be explicit: I think that is a bug. But I need your help with more information.

Bryan

On Apr 17, 2018, at 07:42, Bryan Van de ven [email protected] wrote:

Meir,

Well, as I said, there should the script runs on every session, to create a Document for that session. And there should oonly be one large update at the end of s script, with a completed document for the session. If that’s not happening, it’s worth investigating because it’s not expected. But again, what would be helpful is information to reproduce: a complete script, and a description of your methodology/process that leads you to conclude that messages are being sent early (before the script finishes on each connection).

Thanks,

Bryan

On Apr 17, 2018, at 04:02, Meir Tseitlin [email protected] wrote:

I tried passing arguments like:

figure (… ,
      legend = Legend(
          location = "top_left",
          border_line_alpha = 0.5,
          border_line_width = 0,
          border_line_color = col,
          background_fill_color = fil_col,
          background_fill_alpha = 0.5,
          label_text_color = text.col,
          click_policy = "hide",
      ))
without any success…

On Tuesday, April 17, 2018 at 1:52:41 PM UTC+3, Meir Tseitlin wrote:

Well, that’s exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style plot.title.text = "foo" calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.

The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:

fig.line(

fig.legend.border_line_alpha = 0.5

fig.grid.grid_line_alpha =

fig.xaxis.axis_line_color =

fig.xaxis.formatter = FuncTickFormatter

fig.y_range.renderers.append(

fig.add_layout(Arrow(end=

fig.x_range.callback = CustomJS(

Thanks

On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:
Hi,

Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like
  plot.title.text = "foo"
that automatically sends a “patch” message over the webscocket to reflect that single change. However, that should really only be the case be subsequent changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?

Thanks,

Bryan

On Apr 16, 2018, at 09:06, Meir Tseitlin [email protected] wrote:

I am trying to optimize Bokeh load time when working with server and I am having few questions:

(1)
From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:

I am having “figure” command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it’s own socket traffic - which means it’s heavy. Multiplied by the amount of figures - it creates a significant overhead.

If this is true, is there a way to pass all those instructions directly to “figure” command, instead of updating them afterwards?

(2)
I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic… (it’s not a question - just an observation)

(3)
Are there any other ways to reduce the initialization overhead?

Tnx
Meir Tseitlin

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/408ad348-2757-437c-bfa6-6b18fdf003fb%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · April 17, 2018, 6:39pm

So I instrumented the write_message function and as far as I can tell the server seems to be sending PATCH-DOC messages that I would regard as extraneous. So, this situation should be investigated to see what improvement can be made to reduce this noise. Can you open a GitHub issue with this information?

Thanks,

Bryan

···

On Apr 17, 2018, at 11:18, Meir Tseitlin <[email protected]> wrote:

That's the case exactly,
Yes when I am opening a socket view in Chrome I am seeing something like this:

After initial few "heavy" transfers, there are ~100+ small updates like you see in the screenshot. (I am not sure how to copy-paste the exact log from Chrome - looks like it is not supported)

On Tuesday, April 17, 2018 at 8:57:17 PM UTC+3, Bryan Van de ven wrote:
To be completely explicit, this code:

        from bokeh.io import curdoc
        from bokeh.plotting import figure

        p = figure()
        p.background_fill_alpha = 0.5

        curdoc().add_root(p)

Should only make *one* big web socket message (per session) to initialize the complete document on the JS side. You seem to be saying that this is not the case. I am asking how you have determined this, so that we may try to reproduce your finding.

Thanks,

Bryan

> On Apr 17, 2018, at 09:25, Bryan Van de ven <[email protected]> wrote:
>
> Hi,
>
> We seem to be miscommunicating. What I am asking to know is: how are you actually certain that these extra messages are getting sent, because as I have said, there should not be any. They s hours only be one init message with a compete document. Otherwise, to be explicit: I think that is a bug. But I need your help with more information.
>
> Bryan
>
>> On Apr 17, 2018, at 07:42, Bryan Van de ven <[email protected]> wrote:
>>
>> Meir,
>>
>> Well, as I said, there should the script runs on every session, to create a Document for that session. And there should oonly be one large update at the end of s script, with a completed document for the session. If that's not happening, it's worth investigating because it's not expected. But again, what would be helpful is information to reproduce: a complete script, and a description of your methodology/process that leads you to conclude that messages are being sent early (before the script finishes on each connection).
>>
>> Thanks,
>>
>> Bryan
>>
>>> On Apr 17, 2018, at 04:02, Meir Tseitlin <[email protected]> wrote:
>>>
>>> I tried passing arguments like:
>>> figure (.... ,
>>> legend = Legend(
>>> location = "top_left",
>>> border_line_alpha = 0.5,
>>> border_line_width = 0,
>>> border_line_color = col,
>>> background_fill_color = fil_col,
>>> background_fill_alpha = 0.5,
>>> label_text_color = text.col,
>>> click_policy = "hide",
>>> ))
>>>
>>> without any success.....
>>>
>>> On Tuesday, April 17, 2018 at 1:52:41 PM UTC+3, Meir Tseitlin wrote:
>>>
>>>
>>> Well, that's exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style `plot.title.text = "foo"` calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.
>>>
>>> The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:
>>> * fig.line(
>>> * fig.legend.border_line_alpha = 0.5
>>> * fig.grid.grid_line_alpha =
>>> * fig.xaxis.axis_line_color =
>>> * fig.xaxis.formatter = FuncTickFormatter
>>> * fig.y_range.renderers.append(
>>> * fig.add_layout(Arrow(end=
>>> * fig.x_range.callback = CustomJS(
>>>
>>> Thanks
>>>
>>> On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:
>>> Hi,
>>>
>>> Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like
>>>
>>> plot.title.text = "foo"
>>>
>>> that automatically sends a "patch" message over the webscocket to reflect that single change. However, that should really only be the case be *subsequent* changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?
>>>
>>> Thanks,
>>>
>>> Bryan
>>>
>>>
>>>> On Apr 16, 2018, at 09:06, Meir Tseitlin <[email protected]> wrote:
>>>>
>>>> I am trying to optimize Bokeh load time when working with server and I am having few questions:
>>>>
>>>> (1)
>>>> From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:
>>>> * I am having "figure" command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it's own socket traffic - which means it's heavy. Multiplied by the amount of figures - it creates a significant overhead.
>>>> * If this is true, is there a way to pass all those instructions directly to "figure" command, instead of updating them afterwards?
>>>>
>>>> (2)
>>>> I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic.... (it's not a question - just an observation)
>>>>
>>>> (3)
>>>> Are there any other ways to reduce the initialization overhead?
>>>>
>>>> Tnx
>>>> Meir Tseitlin
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
>>>> To post to this group, send email to bo...@continuum.io.
>>>> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io\.
>>>> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
>>> To post to this group, send email to bo...@continuum.io.
>>> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/408ad348-2757-437c-bfa6-6b18fdf003fb%40continuum.io\.
>>> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
>>

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/4e361659-e6f5-42f0-bb01-e79b1312aa29%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

Meir_Tseitlin · April 17, 2018, 8:27pm

I’ll try to report it properly…

Actually I maybe I found another cause of performance degradation:

The following code reduces the overall performance of the application extremely (including zoom-in zoom-out, pan) and especially in IE11, it’s even causes the fan of the CPU to go up:

fig.xaxis.formatter = FuncTickFormatter(code = """

    date = new Date(tick);
    return date.toLocaleDateString('en-EN', {
      hour: '2-digit',
      minute: '2-digit',
      hour12: false,
      month: 'short',
      day: 'numeric'
    }).replace(',', '');
""")

···

On Tuesday, April 17, 2018 at 9:39:49 PM UTC+3, Bryan Van de ven wrote:

So I instrumented the write_message function and as far as I can tell the server seems to be sending PATCH-DOC messages that I would regard as extraneous. So, this situation should be investigated to see what improvement can be made to reduce this noise. Can you open a GitHub issue with this information?

Thanks,

Bryan

On Apr 17, 2018, at 11:18, Meir Tseitlin [email protected] wrote:

That’s the case exactly,

Yes when I am opening a socket view in Chrome I am seeing something like this:

After initial few “heavy” transfers, there are ~100+ small updates like you see in the screenshot. (I am not sure how to copy-paste the exact log from Chrome - looks like it is not supported)

On Tuesday, April 17, 2018 at 8:57:17 PM UTC+3, Bryan Van de ven wrote:
To be completely explicit, this code:
    from [bokeh.io](http://bokeh.io) import curdoc
    from bokeh.plotting import figure

    p = figure()
    p.background_fill_alpha = 0.5

    curdoc().add_root(p)
Should only make one big web socket message (per session) to initialize the complete document on the JS side. You seem to be saying that this is not the case. I am asking how you have determined this, so that we may try to reproduce your finding.

Thanks,

Bryan
On Apr 17, 2018, at 09:25, Bryan Van de ven [email protected] wrote:

Hi,

We seem to be miscommunicating. What I am asking to know is: how are you actually certain that these extra messages are getting sent, because as I have said, there should not be any. They s hours only be one init message with a compete document. Otherwise, to be explicit: I think that is a bug. But I need your help with more information.

Bryan
On Apr 17, 2018, at 07:42, Bryan Van de ven [email protected] wrote:

Meir,

Well, as I said, there should the script runs on every session, to create a Document for that session. And there should oonly be one large update at the end of s script, with a completed document for the session. If that’s not happening, it’s worth investigating because it’s not expected. But again, what would be helpful is information to reproduce: a complete script, and a description of your methodology/process that leads you to conclude that messages are being sent early (before the script finishes on each connection).

Thanks,

Bryan
On Apr 17, 2018, at 04:02, Meir Tseitlin [email protected] wrote:

I tried passing arguments like:
figure (… ,
legend = Legend(
location = “top_left”,
border_line_alpha = 0.5,
border_line_width = 0,
border_line_color = col,
background_fill_color = fil_col,
background_fill_alpha = 0.5,
label_text_color = text.col,
click_policy = “hide”,
))

without any success…

On Tuesday, April 17, 2018 at 1:52:41 PM UTC+3, Meir Tseitlin wrote:

Well, that’s exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style plot.title.text = "foo" calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.

The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:

fig.line(

fig.legend.border_line_alpha = 0.5

fig.grid.grid_line_alpha =

fig.xaxis.axis_line_color =

fig.xaxis.formatter = FuncTickFormatter

fig.y_range.renderers.append(

fig.add_layout(Arrow(end=

fig.x_range.callback = CustomJS(

Thanks

On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:
Hi,

Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like
  plot.title.text = "foo"
that automatically sends a “patch” message over the webscocket to reflect that single change. However, that should really only be the case be subsequent changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?

Thanks,

Bryan

On Apr 16, 2018, at 09:06, Meir Tseitlin [email protected] wrote:

I am trying to optimize Bokeh load time when working with server and I am having few questions:

(1)
From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:

I am having “figure” command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it’s own socket traffic - which means it’s heavy. Multiplied by the amount of figures - it creates a significant overhead.

If this is true, is there a way to pass all those instructions directly to “figure” command, instead of updating them afterwards?

(2)
I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic… (it’s not a question - just an observation)

(3)
Are there any other ways to reduce the initialization overhead?

Tnx
Meir Tseitlin

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/408ad348-2757-437c-bfa6-6b18fdf003fb%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.
–
You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/4e361659-e6f5-42f0-bb01-e79b1312aa29%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Bryan · April 17, 2018, 8:58pm

Hi,

Great I look forward to seeing the issue and investigating further.

Regarding the tick formatter, once users are using their own JS, they are on their own. There is no possible way we can guarantee than any and all JS that a user might put in a CustomJS will work well, or at all. Tick formatters get called alot -- i.e. every tick is formatted on every draw and if you pan or zoom rapidly then that means every tick is formatted at a very rapid rate. If your tick formatter is doing something expensive then it may just not be suitable for interactive use.

Thanks,

Bryan

···

On Apr 17, 2018, at 13:27, Meir Tseitlin <[email protected]> wrote:

I'll try to report it properly....

Actually I maybe I found another cause of performance degradation:

The following code reduces the overall performance of the application extremely (including zoom-in zoom-out, pan) and especially in IE11, it's even causes the fan of the CPU to go up:

fig.xaxis.formatter = FuncTickFormatter(code = """

    date = new Date(tick);
    return date.toLocaleDateString('en-EN', {
      hour: '2-digit',
      minute: '2-digit',
      hour12: false,
      month: 'short',
      day: 'numeric'
    }).replace(',', '');
""")

On Tuesday, April 17, 2018 at 9:39:49 PM UTC+3, Bryan Van de ven wrote:
So I instrumented the write_message function and as far as I can tell the server seems to be sending PATCH-DOC messages that I would regard as extraneous. So, this situation should be investigated to see what improvement can be made to reduce this noise. Can you open a GitHub issue with this information?

Thanks,

Bryan

> On Apr 17, 2018, at 11:18, Meir Tseitlin <[email protected]> wrote:
>
> That's the case exactly,
> Yes when I am opening a socket view in Chrome I am seeing something like this:
>
>
>
>
> After initial few "heavy" transfers, there are ~100+ small updates like you see in the screenshot. (I am not sure how to copy-paste the exact log from Chrome - looks like it is not supported)
>
>
>
> On Tuesday, April 17, 2018 at 8:57:17 PM UTC+3, Bryan Van de ven wrote:
> To be completely explicit, this code:
>
> from bokeh.io import curdoc
> from bokeh.plotting import figure
>
> p = figure()
> p.background_fill_alpha = 0.5
>
> curdoc().add_root(p)
>
> Should only make *one* big web socket message (per session) to initialize the complete document on the JS side. You seem to be saying that this is not the case. I am asking how you have determined this, so that we may try to reproduce your finding.
>
> Thanks,
>
> Bryan
>
>
> > On Apr 17, 2018, at 09:25, Bryan Van de ven <[email protected]> wrote:
> >
> > Hi,
> >
> > We seem to be miscommunicating. What I am asking to know is: how are you actually certain that these extra messages are getting sent, because as I have said, there should not be any. They s hours only be one init message with a compete document. Otherwise, to be explicit: I think that is a bug. But I need your help with more information.
> >
> > Bryan
> >
> >> On Apr 17, 2018, at 07:42, Bryan Van de ven <[email protected]> wrote:
> >>
> >> Meir,
> >>
> >> Well, as I said, there should the script runs on every session, to create a Document for that session. And there should oonly be one large update at the end of s script, with a completed document for the session. If that's not happening, it's worth investigating because it's not expected. But again, what would be helpful is information to reproduce: a complete script, and a description of your methodology/process that leads you to conclude that messages are being sent early (before the script finishes on each connection).
> >>
> >> Thanks,
> >>
> >> Bryan
> >>
> >>> On Apr 17, 2018, at 04:02, Meir Tseitlin <[email protected]> wrote:
> >>>
> >>> I tried passing arguments like:
> >>> figure (.... ,
> >>> legend = Legend(
> >>> location = "top_left",
> >>> border_line_alpha = 0.5,
> >>> border_line_width = 0,
> >>> border_line_color = col,
> >>> background_fill_color = fil_col,
> >>> background_fill_alpha = 0.5,
> >>> label_text_color = text.col,
> >>> click_policy = "hide",
> >>> ))
> >>>
> >>> without any success.....
> >>>
> >>> On Tuesday, April 17, 2018 at 1:52:41 PM UTC+3, Meir Tseitlin wrote:
> >>>
> >>>
> >>> Well, that's exactly my case - to initialize the plot (actually 3-4 plots in a layout). I am creating a figure and later doing many style `plot.title.text = "foo"` calls for each plot. And while analyzing the socket traffic - I got an impression those subsequent calls are delaying the initialization.
> >>>
> >>> The problem is I am not sure how to do all of it during figure creation (it is not clear from documentation), some examples:
> >>> * fig.line(
> >>> * fig.legend.border_line_alpha = 0.5
> >>> * fig.grid.grid_line_alpha =
> >>> * fig.xaxis.axis_line_color =
> >>> * fig.xaxis.formatter = FuncTickFormatter
> >>> * fig.y_range.renderers.append(
> >>> * fig.add_layout(Arrow(end=
> >>> * fig.x_range.callback = CustomJS(
> >>>
> >>> Thanks
> >>>
> >>> On Monday, April 16, 2018 at 7:55:48 PM UTC+3, Bryan Van de ven wrote:
> >>> Hi,
> >>>
> >>> Bokeh synchronizes Model properties individually, and auto-magically, i.e. when you do something like
> >>>
> >>> plot.title.text = "foo"
> >>>
> >>> that automatically sends a "patch" message over the webscocket to reflect that single change. However, that should really only be the case be *subsequent* changes after startup. At init time, a single entire Bokeh document should be sent. Can you elaborate on both the exact sort of code you used, as well as the methodology?
> >>>
> >>> Thanks,
> >>>
> >>> Bryan
> >>>
> >>>
> >>>> On Apr 16, 2018, at 09:06, Meir Tseitlin <[email protected]> wrote:
> >>>>
> >>>> I am trying to optimize Bokeh load time when working with server and I am having few questions:
> >>>>
> >>>> (1)
> >>>> From analyzing socket traffic it seems that it takes more traffic to send different initialization commands and not the data itself:
> >>>> * I am having "figure" command followed by multiple visualization tune instructions (colors, alpha, legend, tools, etc). Suddenly I realized that each instruction creates it's own socket traffic - which means it's heavy. Multiplied by the amount of figures - it creates a significant overhead.
> >>>> * If this is true, is there a way to pass all those instructions directly to "figure" command, instead of updating them afterwards?
> >>>>
> >>>> (2)
> >>>> I am using json protocol (because binary procotol is still broken when loading via IE11). Which means if I am reducing decimal spaces of my data - it reduces the overall traffic.... (it's not a question - just an observation)
> >>>>
> >>>> (3)
> >>>> Are there any other ways to reduce the initialization overhead?
> >>>>
> >>>> Tnx
> >>>> Meir Tseitlin
> >>>>
> >>>> --
> >>>> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> >>>> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> >>>> To post to this group, send email to bo...@continuum.io.
> >>>> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/9a7942b8-5889-48a8-94b6-b4f705aad6e5%40continuum.io\.
> >>>> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
> >>>
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> >>> To post to this group, send email to bo...@continuum.io.
> >>> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/408ad348-2757-437c-bfa6-6b18fdf003fb%40continuum.io\.
> >>> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.
> >>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.
> To post to this group, send email to bo...@continuum.io.
> To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/4e361659-e6f5-42f0-bb01-e79b1312aa29%40continuum.io\.
> For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

--
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/f68c9ed5-d2fb-44d4-bf39-dbd503d67e95%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.