bokeh version >0.12.10 incredibly slow

Will do. I’m tracking down the latest commit where adding request_paint back still fixes this issue. Will post to GH with all of this info today.

Thanks Bryan

···

On Sunday, April 8, 2018 at 1:16:20 PM UTC-4, Bryan Van de ven wrote:

Dan,

Can you make a GH issue with this new information? That will make it easier to engage other devs in the discussion.

Thanks,

Bryan

On Apr 7, 2018, at 20:52, [email protected] wrote:

The change below, in line 531 of

bokehjs/src/coffee/models/plots/plot_canvas.coffee

is the culprit of my long delay for figure updates. I installed Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e (which has long delays in my figure updates), but manually changed line 531 back to @request_paint(), and the lag went away.

  • @request_paint()
  • XXX: can’t be @request_paint(), because it would trigger back-and-forth

  • layout recomputing feedback loop between plots. Plots are also much more

  • responsive this way, especially in interactive mode.

  • @paint()
    On Saturday, April 7, 2018 at 9:16:56 PM UTC-4, dan.cu…@gmail.com wrote:

On Nov 15, 2017:

Works smoothly, as expected:

Commit a14babf9faed8dcb6f93101630a49636629eaa19

This next commit causes significant delays to my figure updates after an update do its column source data

Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e

https://github.com/bokeh/bokeh/commit/3edfdaf0913b523def90ec1fcc84943cdb371a2e

This is not the only culprit to the slow down I’ve noticed, but it definitely significant

On Saturday, April 7, 2018 at 4:07:05 PM UTC-4, [email protected] wrote:

I evaluated the javascript console log using trace log level and isolated all messages with an elapsed time of > 1sec not due to delays in user interaction (i.e., i waited a few minutes in between clicking a button or drop down).

All of the delayed messages happen in data_range1d.js and glyph_renderer.js… with only one in session.js

I know this still isn’t quite enough to go on for you. But wanted to share. My next plan of attack is to install various commits to see if i can isolate a specific commit, and maybe even some code… might take a while.

Elapsed Time (sec)
Message
2.785
15:10:37.319 data_range1d.js:93 [bokeh]

  • GlyphRenderer46d6249f-62cc-41cf-b10a-829097518b4c
    1.012
    15:10:42.568 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    12.534
    15:10:44.942 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.34
    15:15:18.139 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.113
    15:15:23.993 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.851
    15:15:25.112 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.148
    15:15:27.968 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.541
    15:15:31.130 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.235
    15:15:33.200 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 2ms
    3.217
    15:15:34.441 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.572
    15:15:37.664 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.045
    15:15:40.400 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 17ms
    2.011
    15:15:41.469 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.349
    15:23:28.977 session.js:82 [bokeh] Unhandled OK
    replytoBE03B1184AB9478AB175DC4901D3F4BF
    4.067
    15:23:30.332 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.997
    15:23:34.405 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.142
    15:23:37.689 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.434
    15:23:38.855 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.48
    15:23:41.923 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 1ms
    4.516
    15:23:43.408 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    3.682
    15:23:47.928 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.166
    15:23:51.749 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.843
    15:23:52.937 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    On Saturday, April 7, 2018 at 1:55:12 PM UTC-4, Bryan Van de ven wrote:

It possibly points to some ideas, but unfortunately there is no getting around the necessity of a reproducer in this instance. Investigation will require running code with additional debugging output and other instrumentation, and if there are any potential mitigations, confirming any improvements will require running code too. Anything else is just guess work.

Thanks,

Bryan

On Apr 7, 2018, at 11:11, [email protected] wrote:

When initially accessing my bokeh app via Chrome, i get the following messages in bokeh 0.12.11 and 0.12.15… but not in 0.12.10

0.12.11

index.js:118 [bokeh] document idle at 7294 ms

0.12.15

document.js:188 [bokeh] document idle at 7330 ms

Does this help track down the issue at all?

On Friday, April 6, 2018 at 2:15:04 PM UTC-4, [email protected] wrote:

Any chance any of these could cause significant delays in view update? I have essentially zero experience with JS.

With Bokeh 0.12.15:

A new frequent error:

Uncaught
TypeError: Cannot read property ‘is_empty’ of null

at e.inspect (

selection_manager.js:56

)

at e._inspect (

hover_tool.js:212

)

at e._clear (

hover_tool.js:174

)

at e._move_exit (

hover_tool.js:190

)

at e.<anonymous> (

ui_events.js:128

)

at t.emit (

signaling.js:60

)

at t.trigger (

ui_events.js:293

)

at

ui_events.js:256

at Array.map (<anonymous>)
at t._trigger (

ui_events.js:255)

e.inspect @ selection_manager.js:56

e._inspect @ hover_tool.js:212

e._clear @ hover_tool.js:174

e._move_exit @ hover_tool.js:190

(anonymous) @ ui_events.js:128

t.emit @ signaling.js:60

t.trigger @ ui_events.js:293

(anonymous) @ ui_events.js:256

t._trigger @ ui_events.js:255

t._mouse_exit @ ui_events.js:391

(anonymous) @ ui_events.js:93

Common warnings in both 0.12.10 and 0.12.15:

could not set initial ranges

e.set_initial_range @ plot_canvas.js:635

e.paint @ plot_canvas.js:789

e.repaint @ plot_canvas.js:713

(anonymous) @ plot_canvas.js:572

t.emit @ signaling.js:60

e.emit @ signaling.js:73

(anonymous) @ plot_canvas.js:135

s @ throttle.js:28

requestAnimationFrame (async)

(anonymous) @ throttle.js:37

e.request_paint @ plot_canvas.js:94

e.request_render @ plot_canvas.js:90

e.request_render @ renderer.js:28

e.set_data @ glyph_renderer.js:184

(anonymous) @ glyph_renderer.js:103

t.emit @ signaling.js:60

e.emit @ signaling.js:73

e._setv @ has_props.js:228

e.setv @ has_props.js:251

t.apply_json_patch @ document.js:747

t._handle_patch @ session.js:79

t.handle @ session.js:23

t._steady_state_handler @ connection.js:275

ACK.t.msgtype._current_handler @ connection.js:256

t._on_message @ connection.js:217

t.socket.onmessage @ connection.js:67

And:

jquery-ui is required to enable DataTable.reorderable

t.render @ data_table.js:206

e._layout @ layout_dom.js:187

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._do_layout @ layout_dom.js:169

e.layout @ layout_dom.js:152

e.renderTo @ dom_view.js:42

n @ embed.js:101

l @ embed.js:114

(anonymous) @ embed.js:144

(anonymous) @ es6-promise.js:281

f @ es6-promise.js:290

p @ es6-promise.js:268

r @ es6-promise.js:102

characterData (async)

(anonymous) @ es6-promise.js:81

k @ es6-promise.js:45

c @ es6-promise.js:235

a @ es6-promise.js:205

l @ es6-promise.js:217

(anonymous) @ es6-promise.js:320

t._steady_state_handler @ connection.js:273

ACK.t.msgtype._current_handler @ connection.js:256

t._on_message @ connection.js:217

t.socket.onmessage @ connection.js:67

On Friday, April 6, 2018 at 12:26:47 PM UTC-4, [email protected] wrote:

That feature might be helpful.

It’s still very peculiar to me that 0.12.10 is very smooth with all of these objects.

I’ll keep poking around and let you know what I find.

Thanks Bryan

On Friday, April 6, 2018 at 12:19:42 PM UTC-4, Bryan Van de ven wrote:

That’s probably too much for Bokeh’s layout constraint solver, since everything gets considered together. (Though that is only speculation at this point) The next release will have the ability to place individual server app items in templates, so that reliance Bokeh’s layout system can be minimized or avoided.

Thanks,

Bryan

On Apr 6, 2018, at 11:15, [email protected] wrote:

Tables: 18
Figures: 7
Text fields: 25
Dropdowns: 30
Butons: 21
Other: 15 (radio buttons, check boxes, etc)

On Friday, April 6, 2018 at 12:07:41 PM UTC-4, Bryan Van de ven wrote:
Oh, this might be an issue with layout performance then. What exactly does “lots of objects” mean?

Bryan

On Apr 6, 2018, at 11:05, [email protected] wrote:

The slow down appears to occur in the browser. If I turn off the bokeh server after the terminal has indicated all data updates have been completed, my browser will eventually display the changes.

I have 9 tabs, each with lots of objects in each. The webpage is relatively quick if I cut that down to 2, no one tab appears to be the sole culprit. But still slower than 0.12.10. My concern is that Bokeh 0.12.10 can handle all of these objects in one document perfectly fine.

I’m using:
Chrome Version 64.0.3282.186 (Official Build) (64-bit)
Mac OS 10.13.3

WiIl update if I find more and post simple code on GitHub if I can.

On Friday, April 6, 2018 at 11:39:58 AM UTC-4, [email protected] wrote:
This issue persists in 0.12.15. The software I’ve built is basically unusable for Bokeh >0.12.10.

Are there any methods to print an activity log of what bokeh serve is doing during the web view update? I have generated a log within my python code, and the ColumnSourceData is updated in about 0.25 sec. But then it takes another 19 sec for the view to update. Other objects in the view are non-responsive at this time, even the cross-hair in a plot will not update.

I’ll spend some time trying to come up with a simple code to demonstrate this… but my code is pretty massive and currently depends on database access, so this is no easy task to track down.

On Tuesday, February 13, 2018 at 8:47:56 AM UTC-5, chupach wrote:
hello,

see also my comments from 15. of December, just after release of 0.12.11.
I also stick to 0.12.10 since then, which is unfortunate because other bugs have been eliminated.
I was not able to isolate a self contained example from a rather large project.

My comments were from looking at the js console, but it was a bit cryptic (to me). Like unnecessary refresh of non involved canvas when zooming.

On Tuesday, February 13, 2018 at 2:32:15 PM UTC+1, [email protected] wrote:
Bokeh 0.12.14 has the same issue.

But on the bright side, my tables now render without having to scroll them first.

On Thursday, February 8, 2018 at 1:27:12 PM UTC-5, [email protected] wrote:
Thanks Bryan. I’m working with a pretty massive Bokeh project, so it will take a lot of effort to track down some test code. Since 0.12.10 is working great, it hasn’t been a priority to investigate. Seems related to memory management though, from what I can tell my calculations using loaded data is the same… seems like web UI response issue.

I’ll be sure to post on GitHub if I can definitely nail down the issue. Sorry I can’t clarify further right now.

On Monday, February 5, 2018 at 9:02:32 AM UTC-5, Bryan Van de ven wrote:
Hi,

There are certainly specific situations I have noticed, but nothing I’d describe as general. However, my day to day usage is not an all (or even most) platforms. But to investigate a performance problem we would really need:

  • a GitHub issue
  • with complete test case code
  • platform/browser/version info

Thanks,

Bryan

On Feb 3, 2018, at 08:39, [email protected] wrote:

Has anyone else noticed a significant slow-down in GUI response starting with 0.12.11? 0.12.13 has the same issue.

In the meantime, I’ve just been sticking with 0.12.10 which works very smoothly.

For example, after I’ve defined a a query, and loaded some data… the tabs are not clickable for an extended period of time. I have a plot connected to a drop down that lets you pick your y-axis, what used to be a near instant update after dropdown selection takes 5 - 10 seconds now, or longer. I tried my code without tabs, same issue… in fact, I can’t even scroll the webpage for several seconds after data is loaded or after a dropdown selection.

Perhaps I could use some downsampling or something, but everything works great in 0.12.10… and I really don’t think I have that much data (no imaging data or anything).

Dan


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/504944ab-9e5f-4ebd-90c8-0f715bdf9e5e%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/6347c507-3963-461e-8170-cce3400ba149%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/bcaad5d4-1c82-4926-8d20-fdb38b6302c2%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/8faf0051-8931-47f9-b302-9502ba8f9ffe%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/896587ae-2a05-4de7-8445-429b6adbb07e%40continuum.io.

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

Quick FYI so not to propagate wrong info, the issue wasn’t with @paint vs @request_paint

it was with the repaint function earlier in plot_canvas.coffee. My next message will be on GH.

···

On Sunday, April 8, 2018 at 1:18:08 PM UTC-4, [email protected] wrote:

Will do. I’m tracking down the latest commit where adding request_paint back still fixes this issue. Will post to GH with all of this info today.

Thanks Bryan

On Sunday, April 8, 2018 at 1:16:20 PM UTC-4, Bryan Van de ven wrote:

Dan,

Can you make a GH issue with this new information? That will make it easier to engage other devs in the discussion.

Thanks,

Bryan

On Apr 7, 2018, at 20:52, [email protected] wrote:

The change below, in line 531 of

bokehjs/src/coffee/models/plots/plot_canvas.coffee

is the culprit of my long delay for figure updates. I installed Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e (which has long delays in my figure updates), but manually changed line 531 back to @request_paint(), and the lag went away.

  • @request_paint()
  • XXX: can’t be @request_paint(), because it would trigger back-and-forth

  • layout recomputing feedback loop between plots. Plots are also much more

  • responsive this way, especially in interactive mode.

  • @paint()
    On Saturday, April 7, 2018 at 9:16:56 PM UTC-4, dan.cu…@gmail.com wrote:

On Nov 15, 2017:

Works smoothly, as expected:

Commit a14babf9faed8dcb6f93101630a49636629eaa19

This next commit causes significant delays to my figure updates after an update do its column source data

Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e

https://github.com/bokeh/bokeh/commit/3edfdaf0913b523def90ec1fcc84943cdb371a2e

This is not the only culprit to the slow down I’ve noticed, but it definitely significant

On Saturday, April 7, 2018 at 4:07:05 PM UTC-4, [email protected] wrote:

I evaluated the javascript console log using trace log level and isolated all messages with an elapsed time of > 1sec not due to delays in user interaction (i.e., i waited a few minutes in between clicking a button or drop down).

All of the delayed messages happen in data_range1d.js and glyph_renderer.js… with only one in session.js

I know this still isn’t quite enough to go on for you. But wanted to share. My next plan of attack is to install various commits to see if i can isolate a specific commit, and maybe even some code… might take a while.

Elapsed Time (sec)
Message
2.785
15:10:37.319 data_range1d.js:93 [bokeh]

  • GlyphRenderer46d6249f-62cc-41cf-b10a-829097518b4c
    1.012
    15:10:42.568 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    12.534
    15:10:44.942 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.34
    15:15:18.139 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.113
    15:15:23.993 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.851
    15:15:25.112 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.148
    15:15:27.968 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.541
    15:15:31.130 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.235
    15:15:33.200 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 2ms
    3.217
    15:15:34.441 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.572
    15:15:37.664 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.045
    15:15:40.400 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 17ms
    2.011
    15:15:41.469 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.349
    15:23:28.977 session.js:82 [bokeh] Unhandled OK
    replytoBE03B1184AB9478AB175DC4901D3F4BF
    4.067
    15:23:30.332 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.997
    15:23:34.405 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.142
    15:23:37.689 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.434
    15:23:38.855 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.48
    15:23:41.923 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 1ms
    4.516
    15:23:43.408 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    3.682
    15:23:47.928 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.166
    15:23:51.749 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.843
    15:23:52.937 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    On Saturday, April 7, 2018 at 1:55:12 PM UTC-4, Bryan Van de ven wrote:

It possibly points to some ideas, but unfortunately there is no getting around the necessity of a reproducer in this instance. Investigation will require running code with additional debugging output and other instrumentation, and if there are any potential mitigations, confirming any improvements will require running code too. Anything else is just guess work.

Thanks,

Bryan

On Apr 7, 2018, at 11:11, [email protected] wrote:

When initially accessing my bokeh app via Chrome, i get the following messages in bokeh 0.12.11 and 0.12.15… but not in 0.12.10

0.12.11

index.js:118 [bokeh] document idle at 7294 ms

0.12.15

document.js:188 [bokeh] document idle at 7330 ms

Does this help track down the issue at all?

On Friday, April 6, 2018 at 2:15:04 PM UTC-4, [email protected] wrote:

Any chance any of these could cause significant delays in view update? I have essentially zero experience with JS.

With Bokeh 0.12.15:

A new frequent error:

Uncaught
TypeError: Cannot read property ‘is_empty’ of null

at e.inspect (

selection_manager.js:56

)

at e._inspect (

hover_tool.js:212

)

at e._clear (

hover_tool.js:174

)

at e._move_exit (

hover_tool.js:190

)

at e.<anonymous> (

ui_events.js:128

)

at t.emit (

signaling.js:60

)

at t.trigger (

ui_events.js:293

)

at

ui_events.js:256

at Array.map (<anonymous>)
at t._trigger (

ui_events.js:255)

e.inspect @ selection_manager.js:56

e._inspect @ hover_tool.js:212

e._clear @ hover_tool.js:174

e._move_exit @ hover_tool.js:190

(anonymous) @ ui_events.js:128

t.emit @ signaling.js:60

t.trigger @ ui_events.js:293

(anonymous) @ ui_events.js:256

t._trigger @ ui_events.js:255

t._mouse_exit @ ui_events.js:391

(anonymous) @ ui_events.js:93

Common warnings in both 0.12.10 and 0.12.15:

could not set initial ranges

e.set_initial_range @ plot_canvas.js:635

e.paint @ plot_canvas.js:789

e.repaint @ plot_canvas.js:713

(anonymous) @ plot_canvas.js:572

t.emit @ signaling.js:60

e.emit @ signaling.js:73

(anonymous) @ plot_canvas.js:135

s @ throttle.js:28

requestAnimationFrame (async)

(anonymous) @ throttle.js:37

e.request_paint @ plot_canvas.js:94

e.request_render @ plot_canvas.js:90

e.request_render @ renderer.js:28

e.set_data @ glyph_renderer.js:184

(anonymous) @ glyph_renderer.js:103

t.emit @ signaling.js:60

e.emit @ signaling.js:73

e._setv @ has_props.js:228

e.setv @ has_props.js:251

t.apply_json_patch @ document.js:747

t._handle_patch @ session.js:79

t.handle @ session.js:23

t._steady_state_handler @ connection.js:275

ACK.t.msgtype._current_handler @ connection.js:256

t._on_message @ connection.js:217

t.socket.onmessage @ connection.js:67

And:

jquery-ui is required to enable DataTable.reorderable

t.render @ data_table.js:206

e._layout @ layout_dom.js:187

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._do_layout @ layout_dom.js:169

e.layout @ layout_dom.js:152

e.renderTo @ dom_view.js:42

n @ embed.js:101

l @ embed.js:114

(anonymous) @ embed.js:144

(anonymous) @ es6-promise.js:281

f @ es6-promise.js:290

p @ es6-promise.js:268

r @ es6-promise.js:102

characterData (async)

(anonymous) @ es6-promise.js:81

k @ es6-promise.js:45

c @ es6-promise.js:235

a @ es6-promise.js:205

l @ es6-promise.js:217

(anonymous) @ es6-promise.js:320

t._steady_state_handler @ connection.js:273

ACK.t.msgtype._current_handler @ connection.js:256

t._on_message @ connection.js:217

t.socket.onmessage @ connection.js:67

On Friday, April 6, 2018 at 12:26:47 PM UTC-4, [email protected] wrote:

That feature might be helpful.

It’s still very peculiar to me that 0.12.10 is very smooth with all of these objects.

I’ll keep poking around and let you know what I find.

Thanks Bryan

On Friday, April 6, 2018 at 12:19:42 PM UTC-4, Bryan Van de ven wrote:

That’s probably too much for Bokeh’s layout constraint solver, since everything gets considered together. (Though that is only speculation at this point) The next release will have the ability to place individual server app items in templates, so that reliance Bokeh’s layout system can be minimized or avoided.

Thanks,

Bryan

On Apr 6, 2018, at 11:15, [email protected] wrote:

Tables: 18
Figures: 7
Text fields: 25
Dropdowns: 30
Butons: 21
Other: 15 (radio buttons, check boxes, etc)

On Friday, April 6, 2018 at 12:07:41 PM UTC-4, Bryan Van de ven wrote:
Oh, this might be an issue with layout performance then. What exactly does “lots of objects” mean?

Bryan

On Apr 6, 2018, at 11:05, [email protected] wrote:

The slow down appears to occur in the browser. If I turn off the bokeh server after the terminal has indicated all data updates have been completed, my browser will eventually display the changes.

I have 9 tabs, each with lots of objects in each. The webpage is relatively quick if I cut that down to 2, no one tab appears to be the sole culprit. But still slower than 0.12.10. My concern is that Bokeh 0.12.10 can handle all of these objects in one document perfectly fine.

I’m using:
Chrome Version 64.0.3282.186 (Official Build) (64-bit)
Mac OS 10.13.3

WiIl update if I find more and post simple code on GitHub if I can.

On Friday, April 6, 2018 at 11:39:58 AM UTC-4, [email protected] wrote:
This issue persists in 0.12.15. The software I’ve built is basically unusable for Bokeh >0.12.10.

Are there any methods to print an activity log of what bokeh serve is doing during the web view update? I have generated a log within my python code, and the ColumnSourceData is updated in about 0.25 sec. But then it takes another 19 sec for the view to update. Other objects in the view are non-responsive at this time, even the cross-hair in a plot will not update.

I’ll spend some time trying to come up with a simple code to demonstrate this… but my code is pretty massive and currently depends on database access, so this is no easy task to track down.

On Tuesday, February 13, 2018 at 8:47:56 AM UTC-5, chupach wrote:
hello,

see also my comments from 15. of December, just after release of 0.12.11.
I also stick to 0.12.10 since then, which is unfortunate because other bugs have been eliminated.
I was not able to isolate a self contained example from a rather large project.

My comments were from looking at the js console, but it was a bit cryptic (to me). Like unnecessary refresh of non involved canvas when zooming.

On Tuesday, February 13, 2018 at 2:32:15 PM UTC+1, [email protected] wrote:
Bokeh 0.12.14 has the same issue.

But on the bright side, my tables now render without having to scroll them first.

On Thursday, February 8, 2018 at 1:27:12 PM UTC-5, [email protected] wrote:
Thanks Bryan. I’m working with a pretty massive Bokeh project, so it will take a lot of effort to track down some test code. Since 0.12.10 is working great, it hasn’t been a priority to investigate. Seems related to memory management though, from what I can tell my calculations using loaded data is the same… seems like web UI response issue.

I’ll be sure to post on GitHub if I can definitely nail down the issue. Sorry I can’t clarify further right now.

On Monday, February 5, 2018 at 9:02:32 AM UTC-5, Bryan Van de ven wrote:
Hi,

There are certainly specific situations I have noticed, but nothing I’d describe as general. However, my day to day usage is not an all (or even most) platforms. But to investigate a performance problem we would really need:

  • a GitHub issue
  • with complete test case code
  • platform/browser/version info

Thanks,

Bryan

On Feb 3, 2018, at 08:39, [email protected] wrote:

Has anyone else noticed a significant slow-down in GUI response starting with 0.12.11? 0.12.13 has the same issue.

In the meantime, I’ve just been sticking with 0.12.10 which works very smoothly.

For example, after I’ve defined a a query, and loaded some data… the tabs are not clickable for an extended period of time. I have a plot connected to a drop down that lets you pick your y-axis, what used to be a near instant update after dropdown selection takes 5 - 10 seconds now, or longer. I tried my code without tabs, same issue… in fact, I can’t even scroll the webpage for several seconds after data is loaded or after a dropdown selection.

Perhaps I could use some downsampling or something, but everything works great in 0.12.10… and I really don’t think I have that much data (no imaging data or anything).

Dan


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/504944ab-9e5f-4ebd-90c8-0f715bdf9e5e%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/6347c507-3963-461e-8170-cce3400ba149%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/bcaad5d4-1c82-4926-8d20-fdb38b6302c2%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/8faf0051-8931-47f9-b302-9502ba8f9ffe%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/896587ae-2a05-4de7-8445-429b6adbb07e%40continuum.io.

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

See GH: https://github.com/bokeh/bokeh/issues/7771

···

On Sunday, April 8, 2018 at 2:58:01 PM UTC-4, [email protected] wrote:

Quick FYI so not to propagate wrong info, the issue wasn’t with @paint vs @request_paint

it was with the repaint function earlier in plot_canvas.coffee. My next message will be on GH.

On Sunday, April 8, 2018 at 1:18:08 PM UTC-4, [email protected] wrote:

Will do. I’m tracking down the latest commit where adding request_paint back still fixes this issue. Will post to GH with all of this info today.

Thanks Bryan

On Sunday, April 8, 2018 at 1:16:20 PM UTC-4, Bryan Van de ven wrote:

Dan,

Can you make a GH issue with this new information? That will make it easier to engage other devs in the discussion.

Thanks,

Bryan

On Apr 7, 2018, at 20:52, [email protected] wrote:

The change below, in line 531 of

bokehjs/src/coffee/models/plots/plot_canvas.coffee

is the culprit of my long delay for figure updates. I installed Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e (which has long delays in my figure updates), but manually changed line 531 back to @request_paint(), and the lag went away.

  • @request_paint()
  • XXX: can’t be @request_paint(), because it would trigger back-and-forth

  • layout recomputing feedback loop between plots. Plots are also much more

  • responsive this way, especially in interactive mode.

  • @paint()
    On Saturday, April 7, 2018 at 9:16:56 PM UTC-4, dan.cu…@gmail.com wrote:

On Nov 15, 2017:

Works smoothly, as expected:

Commit a14babf9faed8dcb6f93101630a49636629eaa19

This next commit causes significant delays to my figure updates after an update do its column source data

Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e

https://github.com/bokeh/bokeh/commit/3edfdaf0913b523def90ec1fcc84943cdb371a2e

This is not the only culprit to the slow down I’ve noticed, but it definitely significant

On Saturday, April 7, 2018 at 4:07:05 PM UTC-4, [email protected] wrote:

I evaluated the javascript console log using trace log level and isolated all messages with an elapsed time of > 1sec not due to delays in user interaction (i.e., i waited a few minutes in between clicking a button or drop down).

All of the delayed messages happen in data_range1d.js and glyph_renderer.js… with only one in session.js

I know this still isn’t quite enough to go on for you. But wanted to share. My next plan of attack is to install various commits to see if i can isolate a specific commit, and maybe even some code… might take a while.

Elapsed Time (sec)
Message
2.785
15:10:37.319 data_range1d.js:93 [bokeh]

  • GlyphRenderer46d6249f-62cc-41cf-b10a-829097518b4c
    1.012
    15:10:42.568 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    12.534
    15:10:44.942 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.34
    15:15:18.139 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.113
    15:15:23.993 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.851
    15:15:25.112 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.148
    15:15:27.968 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.541
    15:15:31.130 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.235
    15:15:33.200 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 2ms
    3.217
    15:15:34.441 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.572
    15:15:37.664 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.045
    15:15:40.400 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 17ms
    2.011
    15:15:41.469 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.349
    15:23:28.977 session.js:82 [bokeh] Unhandled OK
    replytoBE03B1184AB9478AB175DC4901D3F4BF
    4.067
    15:23:30.332 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.997
    15:23:34.405 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.142
    15:23:37.689 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.434
    15:23:38.855 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.48
    15:23:41.923 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 1ms
    4.516
    15:23:43.408 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    3.682
    15:23:47.928 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.166
    15:23:51.749 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.843
    15:23:52.937 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    On Saturday, April 7, 2018 at 1:55:12 PM UTC-4, Bryan Van de ven wrote:

It possibly points to some ideas, but unfortunately there is no getting around the necessity of a reproducer in this instance. Investigation will require running code with additional debugging output and other instrumentation, and if there are any potential mitigations, confirming any improvements will require running code too. Anything else is just guess work.

Thanks,

Bryan

On Apr 7, 2018, at 11:11, [email protected] wrote:

When initially accessing my bokeh app via Chrome, i get the following messages in bokeh 0.12.11 and 0.12.15… but not in 0.12.10

0.12.11

index.js:118 [bokeh] document idle at 7294 ms

0.12.15

document.js:188 [bokeh] document idle at 7330 ms

Does this help track down the issue at all?

On Friday, April 6, 2018 at 2:15:04 PM UTC-4, [email protected] wrote:

Any chance any of these could cause significant delays in view update? I have essentially zero experience with JS.

With Bokeh 0.12.15:

A new frequent error:

Uncaught
TypeError: Cannot read property ‘is_empty’ of null

at e.inspect (

selection_manager.js:56

)

at e._inspect (

hover_tool.js:212

)

at e._clear (

hover_tool.js:174

)

at e._move_exit (

hover_tool.js:190

)

at e.<anonymous> (

ui_events.js:128

)

at t.emit (

signaling.js:60

)

at t.trigger (

ui_events.js:293

)

at

ui_events.js:256

at Array.map (<anonymous>)
at t._trigger (

ui_events.js:255)

e.inspect @ selection_manager.js:56

e._inspect @ hover_tool.js:212

e._clear @ hover_tool.js:174

e._move_exit @ hover_tool.js:190

(anonymous) @ ui_events.js:128

t.emit @ signaling.js:60

t.trigger @ ui_events.js:293

(anonymous) @ ui_events.js:256

t._trigger @ ui_events.js:255

t._mouse_exit @ ui_events.js:391

(anonymous) @ ui_events.js:93

Common warnings in both 0.12.10 and 0.12.15:

could not set initial ranges

e.set_initial_range @ plot_canvas.js:635

e.paint @ plot_canvas.js:789

e.repaint @ plot_canvas.js:713

(anonymous) @ plot_canvas.js:572

t.emit @ signaling.js:60

e.emit @ signaling.js:73

(anonymous) @ plot_canvas.js:135

s @ throttle.js:28

requestAnimationFrame (async)

(anonymous) @ throttle.js:37

e.request_paint @ plot_canvas.js:94

e.request_render @ plot_canvas.js:90

e.request_render @ renderer.js:28

e.set_data @ glyph_renderer.js:184

(anonymous) @ glyph_renderer.js:103

t.emit @ signaling.js:60

e.emit @ signaling.js:73

e._setv @ has_props.js:228

e.setv @ has_props.js:251

t.apply_json_patch @ document.js:747

t._handle_patch @ session.js:79

t.handle @ session.js:23

t._steady_state_handler @ connection.js:275

ACK.t.msgtype._current_handler @ connection.js:256

t._on_message @ connection.js:217

t.socket.onmessage @ connection.js:67

And:

jquery-ui is required to enable DataTable.reorderable

t.render @ data_table.js:206

e._layout @ layout_dom.js:187

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._do_layout @ layout_dom.js:169

e.layout @ layout_dom.js:152

e.renderTo @ dom_view.js:42

n @ embed.js:101

l @ embed.js:114

(anonymous) @ embed.js:144

(anonymous) @ es6-promise.js:281

f @ es6-promise.js:290

p @ es6-promise.js:268

r @ es6-promise.js:102

characterData (async)

(anonymous) @ es6-promise.js:81

k @ es6-promise.js:45

c @ es6-promise.js:235

a @ es6-promise.js:205

l @ es6-promise.js:217

(anonymous) @ es6-promise.js:320

t._steady_state_handler @ connection.js:273

ACK.t.msgtype._current_handler @ connection.js:256

t._on_message @ connection.js:217

t.socket.onmessage @ connection.js:67

On Friday, April 6, 2018 at 12:26:47 PM UTC-4, [email protected] wrote:

That feature might be helpful.

It’s still very peculiar to me that 0.12.10 is very smooth with all of these objects.

I’ll keep poking around and let you know what I find.

Thanks Bryan

On Friday, April 6, 2018 at 12:19:42 PM UTC-4, Bryan Van de ven wrote:

That’s probably too much for Bokeh’s layout constraint solver, since everything gets considered together. (Though that is only speculation at this point) The next release will have the ability to place individual server app items in templates, so that reliance Bokeh’s layout system can be minimized or avoided.

Thanks,

Bryan

On Apr 6, 2018, at 11:15, [email protected] wrote:

Tables: 18
Figures: 7
Text fields: 25
Dropdowns: 30
Butons: 21
Other: 15 (radio buttons, check boxes, etc)

On Friday, April 6, 2018 at 12:07:41 PM UTC-4, Bryan Van de ven wrote:
Oh, this might be an issue with layout performance then. What exactly does “lots of objects” mean?

Bryan

On Apr 6, 2018, at 11:05, [email protected] wrote:

The slow down appears to occur in the browser. If I turn off the bokeh server after the terminal has indicated all data updates have been completed, my browser will eventually display the changes.

I have 9 tabs, each with lots of objects in each. The webpage is relatively quick if I cut that down to 2, no one tab appears to be the sole culprit. But still slower than 0.12.10. My concern is that Bokeh 0.12.10 can handle all of these objects in one document perfectly fine.

I’m using:
Chrome Version 64.0.3282.186 (Official Build) (64-bit)
Mac OS 10.13.3

WiIl update if I find more and post simple code on GitHub if I can.

On Friday, April 6, 2018 at 11:39:58 AM UTC-4, [email protected] wrote:
This issue persists in 0.12.15. The software I’ve built is basically unusable for Bokeh >0.12.10.

Are there any methods to print an activity log of what bokeh serve is doing during the web view update? I have generated a log within my python code, and the ColumnSourceData is updated in about 0.25 sec. But then it takes another 19 sec for the view to update. Other objects in the view are non-responsive at this time, even the cross-hair in a plot will not update.

I’ll spend some time trying to come up with a simple code to demonstrate this… but my code is pretty massive and currently depends on database access, so this is no easy task to track down.

On Tuesday, February 13, 2018 at 8:47:56 AM UTC-5, chupach wrote:
hello,

see also my comments from 15. of December, just after release of 0.12.11.
I also stick to 0.12.10 since then, which is unfortunate because other bugs have been eliminated.
I was not able to isolate a self contained example from a rather large project.

My comments were from looking at the js console, but it was a bit cryptic (to me). Like unnecessary refresh of non involved canvas when zooming.

On Tuesday, February 13, 2018 at 2:32:15 PM UTC+1, [email protected] wrote:
Bokeh 0.12.14 has the same issue.

But on the bright side, my tables now render without having to scroll them first.

On Thursday, February 8, 2018 at 1:27:12 PM UTC-5, [email protected] wrote:
Thanks Bryan. I’m working with a pretty massive Bokeh project, so it will take a lot of effort to track down some test code. Since 0.12.10 is working great, it hasn’t been a priority to investigate. Seems related to memory management though, from what I can tell my calculations using loaded data is the same… seems like web UI response issue.

I’ll be sure to post on GitHub if I can definitely nail down the issue. Sorry I can’t clarify further right now.

On Monday, February 5, 2018 at 9:02:32 AM UTC-5, Bryan Van de ven wrote:
Hi,

There are certainly specific situations I have noticed, but nothing I’d describe as general. However, my day to day usage is not an all (or even most) platforms. But to investigate a performance problem we would really need:

  • a GitHub issue
  • with complete test case code
  • platform/browser/version info

Thanks,

Bryan

On Feb 3, 2018, at 08:39, [email protected] wrote:

Has anyone else noticed a significant slow-down in GUI response starting with 0.12.11? 0.12.13 has the same issue.

In the meantime, I’ve just been sticking with 0.12.10 which works very smoothly.

For example, after I’ve defined a a query, and loaded some data… the tabs are not clickable for an extended period of time. I have a plot connected to a drop down that lets you pick your y-axis, what used to be a near instant update after dropdown selection takes 5 - 10 seconds now, or longer. I tried my code without tabs, same issue… in fact, I can’t even scroll the webpage for several seconds after data is loaded or after a dropdown selection.

Perhaps I could use some downsampling or something, but everything works great in 0.12.10… and I really don’t think I have that much data (no imaging data or anything).

Dan


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/504944ab-9e5f-4ebd-90c8-0f715bdf9e5e%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/6347c507-3963-461e-8170-cce3400ba149%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/bcaad5d4-1c82-4926-8d20-fdb38b6302c2%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/8faf0051-8931-47f9-b302-9502ba8f9ffe%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/896587ae-2a05-4de7-8445-429b6adbb07e%40continuum.io.

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

Hi Bryan,

I get the sense there isn’t an interest for Bokeh to support large layouts. On one hand, I’d be happy to continue reviewing the Bokeh source code to find other lines that may cause me lag… but on the other, I don’t want it to be a moot point if larger layouts aren’t regularly tested for future releases.

I think I’ve built something very valuable and unique for my field, but I’m wondering if I should consider a different UI framework if I’m operating outside the scope and intent of Bokeh. I hope that Bokeh would be interested in larger layouts… aside from the initial load time, Bokeh has handled my software very well until recently. And I recently pitched my design to multiple vendors and all were very impressed with the visuals.

I guess I’m asking if I’m pushing Bokeh beyond its scope? If I am, I think I will begin development on another framework. If not, I’ll spend some time thoroughly reviewing the source code to see if I can help.

Thanks,

Dan

···

On Sunday, April 8, 2018 at 4:28:00 PM UTC-4, [email protected] wrote:

See GH: https://github.com/bokeh/bokeh/issues/7771

On Sunday, April 8, 2018 at 2:58:01 PM UTC-4, [email protected] wrote:

Quick FYI so not to propagate wrong info, the issue wasn’t with @paint vs @request_paint

it was with the repaint function earlier in plot_canvas.coffee. My next message will be on GH.

On Sunday, April 8, 2018 at 1:18:08 PM UTC-4, [email protected] wrote:

Will do. I’m tracking down the latest commit where adding request_paint back still fixes this issue. Will post to GH with all of this info today.

Thanks Bryan

On Sunday, April 8, 2018 at 1:16:20 PM UTC-4, Bryan Van de ven wrote:

Dan,

Can you make a GH issue with this new information? That will make it easier to engage other devs in the discussion.

Thanks,

Bryan

On Apr 7, 2018, at 20:52, [email protected] wrote:

The change below, in line 531 of

bokehjs/src/coffee/models/plots/plot_canvas.coffee

is the culprit of my long delay for figure updates. I installed Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e (which has long delays in my figure updates), but manually changed line 531 back to @request_paint(), and the lag went away.

  • @request_paint()
  • XXX: can’t be @request_paint(), because it would trigger back-and-forth

  • layout recomputing feedback loop between plots. Plots are also much more

  • responsive this way, especially in interactive mode.

  • @paint()
    On Saturday, April 7, 2018 at 9:16:56 PM UTC-4, dan.cu…@gmail.com wrote:

On Nov 15, 2017:

Works smoothly, as expected:

Commit a14babf9faed8dcb6f93101630a49636629eaa19

This next commit causes significant delays to my figure updates after an update do its column source data

Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e

https://github.com/bokeh/bokeh/commit/3edfdaf0913b523def90ec1fcc84943cdb371a2e

This is not the only culprit to the slow down I’ve noticed, but it definitely significant

On Saturday, April 7, 2018 at 4:07:05 PM UTC-4, [email protected] wrote:

I evaluated the javascript console log using trace log level and isolated all messages with an elapsed time of > 1sec not due to delays in user interaction (i.e., i waited a few minutes in between clicking a button or drop down).

All of the delayed messages happen in data_range1d.js and glyph_renderer.js… with only one in session.js

I know this still isn’t quite enough to go on for you. But wanted to share. My next plan of attack is to install various commits to see if i can isolate a specific commit, and maybe even some code… might take a while.

Elapsed Time (sec)
Message
2.785
15:10:37.319 data_range1d.js:93 [bokeh]

  • GlyphRenderer46d6249f-62cc-41cf-b10a-829097518b4c
    1.012
    15:10:42.568 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    12.534
    15:10:44.942 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.34
    15:15:18.139 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.113
    15:15:23.993 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.851
    15:15:25.112 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.148
    15:15:27.968 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.541
    15:15:31.130 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.235
    15:15:33.200 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 2ms
    3.217
    15:15:34.441 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.572
    15:15:37.664 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.045
    15:15:40.400 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 17ms
    2.011
    15:15:41.469 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.349
    15:23:28.977 session.js:82 [bokeh] Unhandled OK
    replytoBE03B1184AB9478AB175DC4901D3F4BF
    4.067
    15:23:30.332 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    2.997
    15:23:34.405 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.142
    15:23:37.689 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.434
    15:23:38.855 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    1.48
    15:23:41.923 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 1ms
    4.516
    15:23:43.408 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    3.682
    15:23:47.928 data_range1d.js:93 [bokeh]
  • GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
    1.166
    15:23:51.749 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    2.843
    15:23:52.937 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
    On Saturday, April 7, 2018 at 1:55:12 PM UTC-4, Bryan Van de ven wrote:

It possibly points to some ideas, but unfortunately there is no getting around the necessity of a reproducer in this instance. Investigation will require running code with additional debugging output and other instrumentation, and if there are any potential mitigations, confirming any improvements will require running code too. Anything else is just guess work.

Thanks,

Bryan

On Apr 7, 2018, at 11:11, [email protected] wrote:

When initially accessing my bokeh app via Chrome, i get the following messages in bokeh 0.12.11 and 0.12.15… but not in 0.12.10

0.12.11

index.js:118 [bokeh] document idle at 7294 ms

0.12.15

document.js:188 [bokeh] document idle at 7330 ms

Does this help track down the issue at all?

On Friday, April 6, 2018 at 2:15:04 PM UTC-4, [email protected] wrote:

Any chance any of these could cause significant delays in view update? I have essentially zero experience with JS.

With Bokeh 0.12.15:

A new frequent error:

Uncaught
TypeError: Cannot read property ‘is_empty’ of null

at e.inspect (

selection_manager.js:56

)

at e._inspect (

hover_tool.js:212

)

at e._clear (

hover_tool.js:174

)

at e._move_exit (

hover_tool.js:190

)

at e.<anonymous> (

ui_events.js:128

)

at t.emit (

signaling.js:60

)

at t.trigger (

ui_events.js:293

)

at

ui_events.js:256

at Array.map (<anonymous>)
at t._trigger (

ui_events.js:255)

e.inspect @ selection_manager.js:56

e._inspect @ hover_tool.js:212

e._clear @ hover_tool.js:174

e._move_exit @ hover_tool.js:190

(anonymous) @ ui_events.js:128

t.emit @ signaling.js:60

t.trigger @ ui_events.js:293

(anonymous) @ ui_events.js:256

t._trigger @ ui_events.js:255

t._mouse_exit @ ui_events.js:391

(anonymous) @ ui_events.js:93

Common warnings in both 0.12.10 and 0.12.15:

could not set initial ranges

e.set_initial_range @ plot_canvas.js:635

e.paint @ plot_canvas.js:789

e.repaint @ plot_canvas.js:713

(anonymous) @ plot_canvas.js:572

t.emit @ signaling.js:60

e.emit @ signaling.js:73

(anonymous) @ plot_canvas.js:135

s @ throttle.js:28

requestAnimationFrame (async)

(anonymous) @ throttle.js:37

e.request_paint @ plot_canvas.js:94

e.request_render @ plot_canvas.js:90

e.request_render @ renderer.js:28

e.set_data @ glyph_renderer.js:184

(anonymous) @ glyph_renderer.js:103

t.emit @ signaling.js:60

e.emit @ signaling.js:73

e._setv @ has_props.js:228

e.setv @ has_props.js:251

t.apply_json_patch @ document.js:747

t._handle_patch @ session.js:79

t.handle @ session.js:23

t._steady_state_handler @ connection.js:275

ACK.t.msgtype._current_handler @ connection.js:256

t._on_message @ connection.js:217

t.socket.onmessage @ connection.js:67

And:

jquery-ui is required to enable DataTable.reorderable

t.render @ data_table.js:206

e._layout @ layout_dom.js:187

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._layout @ layout_dom.js:185

e._do_layout @ layout_dom.js:169

e.layout @ layout_dom.js:152

e.renderTo @ dom_view.js:42

n @ embed.js:101

l @ embed.js:114

(anonymous) @ embed.js:144

(anonymous) @ es6-promise.js:281

f @ es6-promise.js:290

p @ es6-promise.js:268

r @ es6-promise.js:102

characterData (async)

(anonymous) @ es6-promise.js:81

k @ es6-promise.js:45

c @ es6-promise.js:235

a @ es6-promise.js:205

l @ es6-promise.js:217

(anonymous) @ es6-promise.js:320

t._steady_state_handler @ connection.js:273

ACK.t.msgtype._current_handler @ connection.js:256

t._on_message @ connection.js:217

t.socket.onmessage @ connection.js:67

On Friday, April 6, 2018 at 12:26:47 PM UTC-4, [email protected] wrote:

That feature might be helpful.

It’s still very peculiar to me that 0.12.10 is very smooth with all of these objects.

I’ll keep poking around and let you know what I find.

Thanks Bryan

On Friday, April 6, 2018 at 12:19:42 PM UTC-4, Bryan Van de ven wrote:

That’s probably too much for Bokeh’s layout constraint solver, since everything gets considered together. (Though that is only speculation at this point) The next release will have the ability to place individual server app items in templates, so that reliance Bokeh’s layout system can be minimized or avoided.

Thanks,

Bryan

On Apr 6, 2018, at 11:15, [email protected] wrote:

Tables: 18
Figures: 7
Text fields: 25
Dropdowns: 30
Butons: 21
Other: 15 (radio buttons, check boxes, etc)

On Friday, April 6, 2018 at 12:07:41 PM UTC-4, Bryan Van de ven wrote:
Oh, this might be an issue with layout performance then. What exactly does “lots of objects” mean?

Bryan

On Apr 6, 2018, at 11:05, [email protected] wrote:

The slow down appears to occur in the browser. If I turn off the bokeh server after the terminal has indicated all data updates have been completed, my browser will eventually display the changes.

I have 9 tabs, each with lots of objects in each. The webpage is relatively quick if I cut that down to 2, no one tab appears to be the sole culprit. But still slower than 0.12.10. My concern is that Bokeh 0.12.10 can handle all of these objects in one document perfectly fine.

I’m using:
Chrome Version 64.0.3282.186 (Official Build) (64-bit)
Mac OS 10.13.3

WiIl update if I find more and post simple code on GitHub if I can.

On Friday, April 6, 2018 at 11:39:58 AM UTC-4, [email protected] wrote:
This issue persists in 0.12.15. The software I’ve built is basically unusable for Bokeh >0.12.10.

Are there any methods to print an activity log of what bokeh serve is doing during the web view update? I have generated a log within my python code, and the ColumnSourceData is updated in about 0.25 sec. But then it takes another 19 sec for the view to update. Other objects in the view are non-responsive at this time, even the cross-hair in a plot will not update.

I’ll spend some time trying to come up with a simple code to demonstrate this… but my code is pretty massive and currently depends on database access, so this is no easy task to track down.

On Tuesday, February 13, 2018 at 8:47:56 AM UTC-5, chupach wrote:
hello,

see also my comments from 15. of December, just after release of 0.12.11.
I also stick to 0.12.10 since then, which is unfortunate because other bugs have been eliminated.
I was not able to isolate a self contained example from a rather large project.

My comments were from looking at the js console, but it was a bit cryptic (to me). Like unnecessary refresh of non involved canvas when zooming.

On Tuesday, February 13, 2018 at 2:32:15 PM UTC+1, [email protected] wrote:
Bokeh 0.12.14 has the same issue.

But on the bright side, my tables now render without having to scroll them first.

On Thursday, February 8, 2018 at 1:27:12 PM UTC-5, [email protected] wrote:
Thanks Bryan. I’m working with a pretty massive Bokeh project, so it will take a lot of effort to track down some test code. Since 0.12.10 is working great, it hasn’t been a priority to investigate. Seems related to memory management though, from what I can tell my calculations using loaded data is the same… seems like web UI response issue.

I’ll be sure to post on GitHub if I can definitely nail down the issue. Sorry I can’t clarify further right now.

On Monday, February 5, 2018 at 9:02:32 AM UTC-5, Bryan Van de ven wrote:
Hi,

There are certainly specific situations I have noticed, but nothing I’d describe as general. However, my day to day usage is not an all (or even most) platforms. But to investigate a performance problem we would really need:

  • a GitHub issue
  • with complete test case code
  • platform/browser/version info

Thanks,

Bryan

On Feb 3, 2018, at 08:39, [email protected] wrote:

Has anyone else noticed a significant slow-down in GUI response starting with 0.12.11? 0.12.13 has the same issue.

In the meantime, I’ve just been sticking with 0.12.10 which works very smoothly.

For example, after I’ve defined a a query, and loaded some data… the tabs are not clickable for an extended period of time. I have a plot connected to a drop down that lets you pick your y-axis, what used to be a near instant update after dropdown selection takes 5 - 10 seconds now, or longer. I tried my code without tabs, same issue… in fact, I can’t even scroll the webpage for several seconds after data is loaded or after a dropdown selection.

Perhaps I could use some downsampling or something, but everything works great in 0.12.10… and I really don’t think I have that much data (no imaging data or anything).

Dan


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/504944ab-9e5f-4ebd-90c8-0f715bdf9e5e%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/6347c507-3963-461e-8170-cce3400ba149%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/bcaad5d4-1c82-4926-8d20-fdb38b6302c2%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/8faf0051-8931-47f9-b302-9502ba8f9ffe%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/896587ae-2a05-4de7-8445-429b6adbb07e%40continuum.io.

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

Hi Dan,

We definitely want Bokeh to be as useful to as many users and uses as possible, but there are many many users, and many many potential uses, and only a handful of developers. Having larger layouts "regularly tested for future releases" means having a person commit to making that happen. If you are offering to become a contributor, craft a suitable test case or example, and to help ensure that its tested during each cycle (or better, to help figure out how it could be tested in an automated way), that would the best defense against regressions in this area.

In any case I can offer a few specific comments:

In the issue, Mateusz describes the possibility that repaint is overly aggressive in terms of deciding when to do a full layout recompute. This seems like an immediately reasonable and narrow avenue of investigation. If that is indeed the case, then hopefully there is a straightforward way to make it not recompute too often. Or if not, if it might possible to add some flag to allow users to restrict or turn off computations altogether in some explicitly described manner (this is not ideal, but it if it simple to add and maintain, and makes some previously inaccessible use cases accessible, it would be worth considering).

It's probably safe to say that for more sophisticated layout use cases, our ambitions regarding layout outstripped our available resources to implement and execute. So it's also worth watching this PR:

  https://github.com/bokeh/bokeh/pull/7708

Which will add the ability for individual document roots to be put into user-defined templates in any way they like. This is essentially a relief value, that will offer a path for user's to entirely bypass Bokeh's global layout when it is not up to their needs. I.e. you could embed all your plots separately in some JS layout framework of your choice.

Thanks,

Bryan

···

On Apr 10, 2018, at 09:39, [email protected] wrote:

Hi Bryan,

I get the sense there isn't an interest for Bokeh to support large layouts. On one hand, I'd be happy to continue reviewing the Bokeh source code to find other lines that may cause me lag... but on the other, I don't want it to be a moot point if larger layouts aren't regularly tested for future releases.

I think I've built something very valuable and unique for my field, but I'm wondering if I should consider a different UI framework if I'm operating outside the scope and intent of Bokeh. I hope that Bokeh would be interested in larger layouts... aside from the initial load time, Bokeh has handled my software very well until recently. And I recently pitched my design to multiple vendors and all were very impressed with the visuals.

I guess I'm asking if I'm pushing Bokeh beyond its scope? If I am, I think I will begin development on another framework. If not, I'll spend some time thoroughly reviewing the source code to see if I can help.

Thanks,

Dan

On Sunday, April 8, 2018 at 4:28:00 PM UTC-4, [email protected] wrote:
See GH: https://github.com/bokeh/bokeh/issues/7771

On Sunday, April 8, 2018 at 2:58:01 PM UTC-4, [email protected] wrote:
Quick FYI so not to propagate wrong info, the issue wasn't with @paint vs @request_paint

it was with the repaint function earlier in plot_canvas.coffee. My next message will be on GH.

On Sunday, April 8, 2018 at 1:18:08 PM UTC-4, [email protected] wrote:
Will do. I'm tracking down the latest commit where adding request_paint back still fixes this issue. Will post to GH with all of this info today.

Thanks Bryan

On Sunday, April 8, 2018 at 1:16:20 PM UTC-4, Bryan Van de ven wrote:
Dan,

Can you make a GH issue with this new information? That will make it easier to engage other devs in the discussion.

Thanks,

Bryan

On Apr 7, 2018, at 20:52, [email protected] wrote:

The change below, in line 531 of
bokehjs/src/coffee/models/plots/plot_canvas.coffee

is the culprit of my long delay for figure updates. I installed Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e (which has long delays in my figure updates), but manually changed line 531 back to @request_paint(), and the lag went away.

- @request_paint()
+ # XXX: can't be @request_paint(), because it would trigger back-and-forth
+ # layout recomputing feedback loop between plots. Plots are also much more
+ # responsive this way, especially in interactive mode.
+ @paint()

On Saturday, April 7, 2018 at 9:16:56 PM UTC-4, [email protected] wrote:
On Nov 15, 2017:
Works smoothly, as expected:
Commit a14babf9faed8dcb6f93101630a49636629eaa19

This next commit causes significant delays to my figure updates after an update do its column source data
Commit 3edfdaf0913b523def90ec1fcc84943cdb371a2e
https://github.com/bokeh/bokeh/commit/3edfdaf0913b523def90ec1fcc84943cdb371a2e

This is not the only culprit to the slow down I've noticed, but it definitely significant

On Saturday, April 7, 2018 at 4:07:05 PM UTC-4, [email protected] wrote:

I evaluated the javascript console log using trace log level and isolated all messages with an elapsed time of > 1sec not due to delays in user interaction (i.e., i waited a few minutes in between clicking a button or drop down).

All of the delayed messages happen in data_range1d.js and glyph_renderer.js... with only one in session.js

I know this still isn't quite enough to go on for you. But wanted to share. My next plan of attack is to install various commits to see if i can isolate a specific commit, and maybe even some code... might take a while.

Elapsed Time (sec) Message
2.785 15:10:37.319 data_range1d.js:93 [bokeh] - GlyphRenderer46d6249f-62cc-41cf-b10a-829097518b4c
1.012 15:10:42.568 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
12.534 15:10:44.942 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
1.34 15:15:18.139 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
1.113 15:15:23.993 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
2.851 15:15:25.112 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
2.148 15:15:27.968 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
1.541 15:15:31.130 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
1.235 15:15:33.200 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 2ms
3.217 15:15:34.441 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
2.572 15:15:37.664 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
1.045 15:15:40.400 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 17ms
2.011 15:15:41.469 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
1.349 15:23:28.977 session.js:82 [bokeh] Unhandled OK replytoBE03B1184AB9478AB175DC4901D3F4BF
4.067 15:23:30.332 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
2.997 15:23:34.405 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
1.142 15:23:37.689 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
2.434 15:23:38.855 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
1.48 15:23:41.923 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 1ms
4.516 15:23:43.408 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
3.682 15:23:47.928 data_range1d.js:93 [bokeh] - GlyphRenderer3c8c70fd-5bc7-4a68-82f4-28c18a6793aa
1.166 15:23:51.749 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms
2.843 15:23:52.937 glyph_renderer.js:328 [bokeh] - glyph renders finished in : 0ms

On Saturday, April 7, 2018 at 1:55:12 PM UTC-4, Bryan Van de ven wrote:
It possibly points to some ideas, but unfortunately there is no getting around the necessity of a reproducer in this instance. Investigation will require running code with additional debugging output and other instrumentation, and if there are any potential mitigations, confirming any improvements will require running code too. Anything else is just guess work.

Thanks,

Bryan

> On Apr 7, 2018, at 11:11, [email protected] wrote:
>
> When initially accessing my bokeh app via Chrome, i get the following messages in bokeh 0.12.11 and 0.12.15... but not in 0.12.10
>
> 0.12.11
> index.js:118 [bokeh] document idle at 7294 ms
>
> 0.12.15
> document.js:188 [bokeh] document idle at 7330 ms
>
> Does this help track down the issue at all?
>
>
> On Friday, April 6, 2018 at 2:15:04 PM UTC-4, [email protected] wrote:
> Any chance any of these could cause significant delays in view update? I have essentially zero experience with JS.
>
>
> With Bokeh 0.12.15:
>
> A new frequent error:
> Uncaught
> TypeError: Cannot read property 'is_empty' of null
> at e.inspect (
> selection_manager.js:56
> )
> at e._inspect (
> hover_tool.js:212
> )
> at e._clear (
> hover_tool.js:174
> )
> at e._move_exit (
> hover_tool.js:190
> )
> at e.<anonymous> (
> ui_events.js:128
> )
> at t.emit (
> signaling.js:60
> )
> at t.trigger (
> ui_events.js:293
> )
> at
> ui_events.js:256
>
> at Array.map (<anonymous>)
> at t._trigger (
> ui_events.js:255)
> e.inspect @ selection_manager.js:56
> e._inspect @ hover_tool.js:212
> e._clear @ hover_tool.js:174
> e._move_exit @ hover_tool.js:190
> (anonymous) @ ui_events.js:128
> t.emit @ signaling.js:60
> t.trigger @ ui_events.js:293
> (anonymous) @ ui_events.js:256
> t._trigger @ ui_events.js:255
> t._mouse_exit @ ui_events.js:391
> (anonymous) @ ui_events.js:93
>
>
>
>
> Common warnings in both 0.12.10 and 0.12.15:
>
> could not set initial ranges
> e.set_initial_range @ plot_canvas.js:635
> e.paint @ plot_canvas.js:789
> e.repaint @ plot_canvas.js:713
> (anonymous) @ plot_canvas.js:572
> t.emit @ signaling.js:60
> e.emit @ signaling.js:73
> (anonymous) @ plot_canvas.js:135
> s @ throttle.js:28
> requestAnimationFrame (async)
> (anonymous) @ throttle.js:37
> e.request_paint @ plot_canvas.js:94
> e.request_render @ plot_canvas.js:90
> e.request_render @ renderer.js:28
> e.set_data @ glyph_renderer.js:184
> (anonymous) @ glyph_renderer.js:103
> t.emit @ signaling.js:60
> e.emit @ signaling.js:73
> e._setv @ has_props.js:228
> e.setv @ has_props.js:251
> t.apply_json_patch @ document.js:747
> t._handle_patch @ session.js:79
> t.handle @ session.js:23
> t._steady_state_handler @ connection.js:275
> ACK.t.msgtype._current_handler @ connection.js:256
> t._on_message @ connection.js:217
> t.socket.onmessage @ connection.js:67
>
> And:
> jquery-ui is required to enable DataTable.reorderable
> t.render @ data_table.js:206
> e._layout @ layout_dom.js:187
> e._layout @ layout_dom.js:185
> e._layout @ layout_dom.js:185
> e._layout @ layout_dom.js:185
> e._layout @ layout_dom.js:185
> e._do_layout @ layout_dom.js:169
> e.layout @ layout_dom.js:152
> e.renderTo @ dom_view.js:42
> n @ embed.js:101
> l @ embed.js:114
> (anonymous) @ embed.js:144
> (anonymous) @ es6-promise.js:281
> f @ es6-promise.js:290
> p @ es6-promise.js:268
> r @ es6-promise.js:102
> characterData (async)
> (anonymous) @ es6-promise.js:81
> k @ es6-promise.js:45
> c @ es6-promise.js:235
> a @ es6-promise.js:205
> l @ es6-promise.js:217
> (anonymous) @ es6-promise.js:320
> t._steady_state_handler @ connection.js:273
> ACK.t.msgtype._current_handler @ connection.js:256
> t._on_message @ connection.js:217
> t.socket.onmessage @ connection.js:67
>
> On Friday, April 6, 2018 at 12:26:47 PM UTC-4, [email protected] wrote:
> That feature might be helpful.
>
> It's still very peculiar to me that 0.12.10 is very smooth with all of these objects.
>
> I'll keep poking around and let you know what I find.
>
> Thanks Bryan
>
> On Friday, April 6, 2018 at 12:19:42 PM UTC-4, Bryan Van de ven wrote:
> That's probably too much for Bokeh's layout constraint solver, since everything gets considered together. (Though that is only speculation at this point) The next release will have the ability to place individual server app items in templates, so that reliance Bokeh's layout system can be minimized or avoided.
>
> Thanks,
>
> Bryan
>
> > On Apr 6, 2018, at 11:15, [email protected] wrote:
> >
> > Tables: 18
> > Figures: 7
> > Text fields: 25
> > Dropdowns: 30
> > Butons: 21
> > Other: 15 (radio buttons, check boxes, etc)
> >
> > On Friday, April 6, 2018 at 12:07:41 PM UTC-4, Bryan Van de ven wrote:
> > Oh, this might be an issue with layout performance then. What exactly does "lots of objects" mean?
> >
> > Bryan
> >
> > > On Apr 6, 2018, at 11:05, [email protected] wrote:
> > >
> > > The slow down appears to occur in the browser. If I turn off the bokeh server after the terminal has indicated all data updates have been completed, my browser will eventually display the changes.
> > >
> > > I have 9 tabs, each with lots of objects in each. The webpage is relatively quick if I cut that down to 2, no one tab appears to be the sole culprit. But still slower than 0.12.10. My concern is that Bokeh 0.12.10 can handle all of these objects in one document perfectly fine.
> > >
> > > I'm using:
> > > Chrome Version 64.0.3282.186 (Official Build) (64-bit)
> > > Mac OS 10.13.3
> > >
> > > WiIl update if I find more and post simple code on GitHub if I can.
> > >
> > > On Friday, April 6, 2018 at 11:39:58 AM UTC-4, [email protected] wrote:
> > > This issue persists in 0.12.15. The software I've built is basically unusable for Bokeh >0.12.10.
> > >
> > > Are there any methods to print an activity log of what bokeh serve is doing during the web view update? I have generated a log within my python code, and the ColumnSourceData is updated in about 0.25 sec. But then it takes another 19 sec for the view to update. Other objects in the view are non-responsive at this time, even the cross-hair in a plot will not update.
> > >
> > > I'll spend some time trying to come up with a simple code to demonstrate this... but my code is pretty massive and currently depends on database access, so this is no easy task to track down.
> > >
> > >
> > > On Tuesday, February 13, 2018 at 8:47:56 AM UTC-5, chupach wrote:
> > > hello,
> > >
> > > see also my comments from 15. of December, just after release of 0.12.11.
> > > I also stick to 0.12.10 since then, which is unfortunate because other bugs have been eliminated.
> > > I was not able to isolate a self contained example from a rather large project.
> > >
> > > My comments were from looking at the js console, but it was a bit cryptic (to me). Like unnecessary refresh of non involved canvas when zooming.
> > >
> > >
> > >
> > >
> > >
> > > On Tuesday, February 13, 2018 at 2:32:15 PM UTC+1, [email protected] wrote:
> > > Bokeh 0.12.14 has the same issue.
> > >
> > > But on the bright side, my tables now render without having to scroll them first.
> > >
> > > On Thursday, February 8, 2018 at 1:27:12 PM UTC-5, [email protected] wrote:
> > > Thanks Bryan. I'm working with a pretty massive Bokeh project, so it will take a lot of effort to track down some test code. Since 0.12.10 is working great, it hasn't been a priority to investigate. Seems related to memory management though, from what I can tell my calculations using loaded data is the same... seems like web UI response issue.
> > >
> > > I'll be sure to post on GitHub if I can definitely nail down the issue. Sorry I can't clarify further right now.
> > >
> > >
> > > On Monday, February 5, 2018 at 9:02:32 AM UTC-5, Bryan Van de ven wrote:
> > > Hi,
> > >
> > > There are certainly specific situations I have noticed, but nothing I'd describe as general. However, my day to day usage is not an all (or even most) platforms. But to investigate a performance problem we would really need:
> > >
> > > * a GitHub issue
> > > * with complete test case code
> > > * platform/browser/version info
> > >
> > > Thanks,
> > >
> > > Bryan
> > >
> > > > On Feb 3, 2018, at 08:39, [email protected] wrote:
> > > >
> > > > Has anyone else noticed a significant slow-down in GUI response starting with 0.12.11? 0.12.13 has the same issue.
> > > >
> > > > In the meantime, I've just been sticking with 0.12.10 which works very smoothly.
> > > >
> > > > For example, after I've defined a a query, and loaded some data.. the tabs are not clickable for an extended period of time. I have a plot connected to a drop down that lets you pick your y-axis, what used to be a near instant update after dropdown selection takes 5 - 10 seconds now, or longer. I tried my code without tabs, same issue... in fact, I can't even scroll the webpage for several seconds after data is loaded or after a dropdown selection.
> > > >
> > > > Perhaps I could use some downsampling or something, but everything works great in 0.12.10... and I really don't think I have that much data (no imaging data or anything).
> > > >
> > > > Dan
> > > >
> > > > --
> > > > 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/504944ab-9e5f-4ebd-90c8-0f715bdf9e5e%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/6347c507-3963-461e-8170-cce3400ba149%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/bcaad5d4-1c82-4926-8d20-fdb38b6302c2%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/8faf0051-8931-47f9-b302-9502ba8f9ffe%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/896587ae-2a05-4de7-8445-429b6adbb07e%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/390612ad-2c87-4d7f-8e0f-43a67b309f0f%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.

Hi Bryan,

I’d be more than happy to contribute! How would I go about doing that? Basically just keep an eye on GH? And keep bugging you guys? :slight_smile:

I can certainly create some test code similar to my layout, but without the database dependencies so anyone can run it, and at least periodically run it manually... I’ll look into automating it.

Dan

Hi Dan,

The first most useful thing is probably an MRE that reproduces the issue without the database or other dependencies. Just something with stubbed out data sources and plots, etc. that runs too slowly. This would be immediately useful (and necessary, really) for investigating whether repaint is too aggressive, and assuming some changes suggest themselves, to judge whether the changes actually work to improve things.

As for automation I think that's for later. Once we have an MRE, and we have changes that demonstrate improvements on the example, then we can figure out how to include it in our existing CI automation. We already run hundreds of example scripts in our CI tests, we might only need to add some kind of "timeout" notion so that the test can fail if it takes too long. If nothing else, having the script means that it can periodically be run manually to make sure its still performing as expected. So a test script or two would definitely be the best first step.

Thanks,

Bryan

···

On Apr 10, 2018, at 12:10, [email protected] wrote:

Hi Bryan,

I’d be more than happy to contribute! How would I go about doing that? Basically just keep an eye on GH? And keep bugging you guys? :slight_smile:

I can certainly create some test code similar to my layout, but without the database dependencies so anyone can run it, and at least periodically run it manually... I’ll look into automating it.

Dan

--
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/4c5d9a90-a369-494f-b59b-5ac447fc9ae3%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.