Archived discussions · Captured October 28, 2026

Optimizing Bokeh plot initialization

Meir_TseitlinApr 16, 2018 #1

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

⌁ Link to post

BryanApr 16, 2018 #2

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 <meir@imubit.com> 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+unsubscribe@continuum.io.
To post to this group, send email to bokeh@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\.

⌁ Link to post

Meir_TseitlinApr 17, 2018 #3

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 me...@imubit.com 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.

⌁ Link to post

Meir_TseitlinApr 17, 2018 #4

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 me...@imubit.com 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.

⌁ Link to post

BryanApr 17, 2018 #5

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 <meir@imubit.com> 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 <me...@imubit.com> 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+unsubscribe@continuum.io.
To post to this group, send email to bokeh@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\.

⌁ Link to post

BryanApr 17, 2018 #6

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 <bryan@bokeh.org> 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 <meir@imubit.com> 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 <me...@imubit.com> 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+unsubscribe@continuum.io.
To post to this group, send email to bokeh@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\.

⌁ Link to post

BryanApr 17, 2018 #7

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 <bryan@bokeh.org> 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 <bryan@bokeh.org> 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 <meir@imubit.com> 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 <me...@imubit.com> 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+unsubscribe@continuum.io.
To post to this group, send email to bokeh@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\.

⌁ Link to post

Meir_TseitlinApr 17, 2018 #8

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 bry...@anaconda.com 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 bry...@anaconda.com 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 me...@imubit.com 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 me...@imubit.com 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.

⌁ Link to post

BryanApr 17, 2018 #9

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 <meir@imubit.com> 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 <bry...@anaconda.com> 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 <bry...@anaconda.com> 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 <me...@imubit.com> 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 <me...@imubit.com> 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+unsubscribe@continuum.io.
To post to this group, send email to bokeh@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\.

⌁ Link to post

Meir_TseitlinApr 17, 2018 #10

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 me...@imubit.com 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 bry...@anaconda.com 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 bry...@anaconda.com 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 me...@imubit.com 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 me...@imubit.com 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.

⌁ Link to post

BryanApr 17, 2018 #11

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 <meir@imubit.com> 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 <me...@imubit.com> 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 <bry...@anaconda.com> 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 <bry...@anaconda.com> 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 <me...@imubit.com> 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 <me...@imubit.com> 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 bokeh+unsubscribe@continuum.io.
To post to this group, send email to bokeh@continuum.io.
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\.

⌁ Link to post

systemJul 21, 2021 #12

⌁ Link to post

End of archived discussion · Replies are disabled