Copying over a discussion that accidentally happened in PM. cc @mateusz and @p-himik
Hi @Bryan, I genuinely tried look at the code to fix but giving up realizing that typescript was too different from anything I do. (I’m mainly a C(network OS)/Python(ML) guy).
So the next best thing I could do is document my findings in the hopes that you might find it useful. Please do take a look at https://drive.google.com/open?id=1_1wRwPD1uDKqKg0FoBWd9dtdxJrnnAZ7
BryanCore Team Member
@codeyman That’s a bit of an apples and oranges comparison in a potentially important regard. Those results are using CDN loading for plotly but not for Bokeh. By default Bokeh loads resources from the Bokeh server itself, if you want to use CDN to load BokehJS (e.g. to take advantage of caching in the browser after a first load) you can set the env var:
Copy to clipboard
BOKEH_RESOURCES=cdn bokeh serve ...
I’ve thought lately it might be worth discussing changing the default to use CDN, but if you can compare results with both using CDN that possibly might add evidence to support such a change.
In my local tests I was using bokeh inline and was running on local host. Loading files was not an issue. The Performance tests done locally point to JS optimization issues.
I ran the audit tool on https://blog.bokeh.org/static/release-1-1-0/large-grid.html. The results are similar (this fetches from cdn). We are using only 39% of the JS code that is actually downloaded. If you had a table, then there will be a lot more code that would have been unused. (You can run it using Chrome->Dev tool-> Coverage and audit tool).
BryanCore Team Member
We are in fact looking into splitting BokehJS in a more fine-grained fashion, but there are definitely limits to how far this can go. As one example: there are dozens of glyph types. Most plots will only use a few. But I can’t imagine any scenario where e.g. things were split up with a distinct separate file per-glyph type. But we might be able to partition at a level of “common” and “less common” glyphs. A similar statement is true of all the interactive plot tools. At the terminal end: splitting BokehJS up in to hundreds of individual tiny files for each distinct model just to optimize this utilization percentage is not a maintenance burden we can support.