-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow initial rendering of element content #24385
Comments
I've noticed it feels a lot slower too. It might be related to the deferred interpreter and socket loading I added recently. We should definitely figure out what's going on though. |
May be related: #25850 |
Possibly related: currently, loading a Canvas workbook (eg. on a workpad switch, or browser reload, if a workbook was already open) causes a
|
We don't have a better way to check if a user has write permissions until granular app permissions goes into security #20277. |
I started timing things and found that the loading of plugins takes a long time too, causing the throbber to show up for a while before any of the elements even load. I opened #27352 as a result. |
Ignoring the plugin slowness for now, I got some timing from some elements, and it's all over the place; some are pretty quick, some take several seconds to resolve. Still working on a way to time expressions better (and hopefully in a more isolated way). In the meantime, here's the output of a workpad with a single page and a single element: The first 3 are basically expected; the expression has no resolved value, the value is fetched, and then the component is re-rendered. All the other lines here are (needless) re-renders (another performance issue to chase down later). The circled line is one of two things... either a re-render later on, or a second resolution of the resolved value. I've seen server functions get called multiple times on load, so I think it could be either one of those things... All these re-renders on mouse move can't be helping the interface lag at all either 😢. |
Eliminating duplicated workbook loading is still blocked by #20277 |
@w33ble I'll check the mousemove issue soon |
@w33ble do you think we can close this issue due to your previous fix or are we still tracking other performance issues? |
I think we can close it. Loading time isn't really a source of problems anymore. |
We currently have similar slow rendering when loading a canvas with a lot of element inside. Our elements mainly image assets, each make requests to determine the rendering of the image Would it be possible to have a mechanism to control the order of rendering ? for example if an element makes a request that takes longer than another, not to wait for the global results to have the global rendering pass. kibana : 7.16.3 |
Kibana version:
8fc3d4 or before on
master
; seen this for a good whileSteps to reproduce:
Expected behavior:
In this case, these are all shapes which don't rely on external resources, so an instantaneous load is anticipated. cc @cqliu1 @w33ble
Screenshots (if relevant):
Errors in browser console (if relevant):
none
Any additional context:
Seems to happen if browser page is left around unused for a longer while; with warm caches the shapes can show up almost immediately.
The text was updated successfully, but these errors were encountered: