Bokeh Server slow update front-end callback with Div .text

Hello Bokeh community,
I would like to post a problem I’m having with updating .text property of a bokeh Div widget when pressing a button in the Front-end. I currently require to update a Div widget with a new calculated text. The problem is that it’s taking too long to reflect the change in th Front-end. I timed the operation in the backend (currently I’m doing a random) but it takes few miliseconds to process and in the front-end it takes around 15 seconds to show the update. I tried using Paragraph widget instead of Div but it didn’t make a difference.
Here is an image of what I’m currently trying to do:


Here is the code for updating the .text Div

def optimizar(self):
	restricciones = {}
	for var in self.var_influyentes:
		condicion1 = self.dyn_row_list[var].low_condition_select.value
		condicion2 = self.dyn_row_list[var].high_condition_select.value
		dict_condicion1 = self.create_dict_condicion(num_condicion=1,
														condicion=condicion1,
														val_condicion_raw=self.dyn_row_list[var].low_inter_text.value)
		dict_condicion2 = self.create_dict_condicion(num_condicion=2,
														condicion=condicion2,
														val_condicion_raw=self.dyn_row_list[var].high_inter_text.value)
		if dict_condicion1:
			dict_condicion1.update(dict_condicion2)
			restricciones.update({var: dict_condicion1})
		self.dyn_row_list[var].var_found_value.text = f'<b>{round(random.uniform(0,20),2)}</b>'

@dvelasquez can you apply code formatting to your post? Either triple bakctick ``` fences around the code, or else use the code format button </> from the editor UI.

The first question is: how much work does the computation in the callback take? If you are doing 15 seconds of work leading up to setting the div text, then the text won’t update before your work is done.

Hello Bryan, I edited my post with code in backticks.
Also, I have made some tests of the total computation time and it takes 0.0012 seconds (see figures)

Code time929×437 29.5 KB

@dvelasquez I am afraid don’t really have any insights. This code:

from bokeh.io import curdoc
from bokeh.layouts import column
from bokeh.models import Button, Div

d = Div(text="start")

b = Button()

def cb(): d.text = "end"
b.on_click(cb)

curdoc().add_root(column(d, b))

updates immediately for me. Does it also update immediately for you? If so, then I think the issue lies in something specific to your code, which means I would need your code (or ideally, a minimal version, just enough to reproduce the issue) to run and investigate in order to say more.

If not, if you are seeing an issue that that toy example, then perhaps there is some platform specific thing going on.

Hello Bryan, I sent you a PM with the GitHub of the project.
Thanks in advance,
David

Hello Bryan, as we discussed through the PM, your minimal example runs well, although the problem with my application seems to be with creating custom made dynamic classes that use bokeh widgets for its instantiation. I will do a jupyter notebook using constants instead of web requests to publish it here in the community to check if anyone may know the possible problem. Thanks

@dvelasquez looking at a browser trace, my best offhand guess is that you are running in to this:

[BUG] Layout engine much slower on Chrome · Issue #9515 · bokeh/bokeh · GitHub

Notice especially the long comment by @mateusz at the bottom. Given the quantity of code I can only offer some suggestions for you to try out yourself. Chiefly, I would suggest combining all the labels and divs into a single Div or PreText that you update with a single property change. Alternatively, you might try giving fixed sizing modes to the Div objects (I don’t know for certain that this will prevent the layout/style invalidations that seem to be the issue, but it’s worth trying)

Hello Bryan, I made a more simplified version of the code in a Jupyter Notebook and commented some sections. Also I included the HTTP requests as constants so it can be made public. Here is the code:
https://gist.github.com/tidusdavid/96e68ad967966830e2023cf52936ec99
I tried using PreText but the problem persists. I will test using the fixed layouts instead of ‘stretch_width’ to see if I get an improvement. With respect to the issue post you sent, I will check if using firefox takes less time.
I would like to add that the part that is taking a lot of time is when using “Optimize”. The steps to reproduce the long front-end response is to execute the whole Jupyter Notebook, then click on the “Optimize” RadioButtonGroup option, then selecting in Condition1 any condition different than ‘-’, then putting any value in the Value1 and pressing the button Optimize.

@dvelasquez unfortunately I am afraid I don’t have any other suggestions at this time. I’d encourage you to chime in on the issue I linked on GitHub as, as far as I can tell, excessive layout computation is related to what you are seeing.