We have a dash AIO component representing a variable sized table. There is a pattern-matching callback processing cell clicks which, for instance, allow in-place editing.
When the table size increases, we notice significant lag (multiple seconds) when cells are clicked before the callback itself triggers. The callbacks are very fast (sub 10ms) and there is no noticeable delay in the network (_dash-update-component takes less than 30ms to fetch, as per the browser).
I suspect it might be related to how dash is building the request, as about hundreds of elements are being added to the request payload. I don’t know how to validate if that’s the case, nor how to fix it if it’s indeed a problem.
Is there a better approach for this problem or any ideas I should pursue?
Thanks for the pointer @AIMPED (and thanks for the fix @spriteware). I was on 2.18.1, so this was very timely.
Time before callback was significantly reduced, so I would say 80% of the problem went away.
I still see a delay between the callback returning and the browser updating the DOM. I’ll try to understand where the issue comes from, but perhaps there are some lingering Ramda calls when parsing the response. I’ll make sure this is not something on my end first.
In my case, about 80% of the time is spent in crawlLayout (half in crawlLayout inside getLayoutCallbacks and another half in crawlLayout inside computePaths).
In the computePaths call tree, note how all the time is spent inside Ramda’s “indexOf”. I suspect something similar is happening in the getLayoutCallbacks call tree.
I understand I have not provided a minimum reproducible example and that it would probably be more appropriate if this was moved to a github issue.
