bokeh version >0.12.10 incredibly slow

[dan.cutright]

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

[Bryan]

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\.

[dan.cutright]

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.

[dan.cutright]

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.

[chupach1]

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.

[dan.cutright]

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.

[dan.cutright]

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.

[Bryan]

Hi,

You can set the environment variable BOKEH_LOG_LEVEL to "debug" or "trace" to get much more output in the browser JS console, including some timings (but mostly related to rendering). You can also set --log-level when you run the server to increase logging on the python side, but I'm not sure how informative that will be.

I'd definitely like to find out what the root cause is of what you are seeing, even if the result is only better or different guidance. But I will be frank and say that having a minimal reproducer is probably the only hope of being able to figure out the specific problem you are encountering. Otherwise my only offhand speculation is that somehow you are doing something that prevents the binary transport option from being used. If you have more information about the size and shape of the data that might be helpful.

Thanks,

Bryan

···

On Apr 6, 2018, at 10:39, [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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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 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/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/cd04b1e1-19b1-481e-ad59-14c3889d7400%40continuum.io\.
For more options, visit https://groups.google.com/a/continuum.io/d/optout\.

[Bryan]

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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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 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/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\.

[dan.cutright]

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.

[dan.cutright]

To be explicit, that’s the total across all tabs.

···

On Friday, April 6, 2018 at 12:15:46 PM UTC-4, [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.

[Bryan]

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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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 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/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 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/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\.

[dan.cutright]

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.

[dan.cutright]

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. (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 ()
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

bokeh-0.12.10_localhost-1523037182976 (46.2 KB)

bokeh-0.12.15_localhost-1523037578191 (49.2 KB)

···

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.

[dan.cutright]

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. (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 ()
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.

[Bryan]

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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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, dan.cu...@gmail.com 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 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/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 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/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 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/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\.

[dan.cutright]

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

localhost-1523129052247.log (1.86 MB)

···

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.

[dan.cutright]

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

Allow to recompute layout when panels' dimensions change (#7197)

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.

[dan.cutright]

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.

[Bryan]

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.