Multiple extension instances load very slow

[d-molkentin]

It looks like the extensions are all parsed, rendered, and data retrieved one after the other, in a serial fashion. This results in the loading time of a dashboard being multiplied by the number of instances of the extensions. Is it possible to reduce the time by loading the extensions in parallel and caching the results or something similar?

[johnDance]

You are correct that they are loaded serially. This is on purpose. If we loaded them in parallel, the commands that an extension calls could interrupt a running command. The results could then be incorrect. As a simple example, the results of initializeAsync and how many dashboard objects exist and their locations could be incomplete.

We do have some ideas about caching. That could help. We are also improving speed, such as for getSummaryData, and getUnderlyingTableData.

As an aside, how many extensions do you have on your dashboard? Are any of them doing getSummaryData or getUnderlyingTableData as they start up?

John

[d-molkentin]

Hi John,

thanks a lot for your fast reply! I understand the need of loading serially.

We use getSummaryData in our extensions, so it would be helpful to improve speed there.

We tested with like ten extensions on one dashboard and it seemed very slow for us. Like having seven seconds of load time only for the extensions. I think one reason for taking that much time is because we are in iFrames. So the code for the same extension has to be loaded and parsed multiple times. But I think there is no chance, that extensions could be loaded without iframes, right?

Daniel

[johnDance]

Hi Daniel Are these your own extensions? If so, make sure you are using the latest features of getSummaryData released and documented in 1.5 (https://github.com/tableau/extensions-api/releases/tag/v1.5.0). For example, if you need just the column info, don't call getSummaryData, use getSummaryColumnsInfo. Make sure you get only the type of information you need from getSummaryData by using the options to remove unneeded data.

Also, if your extensions come from the same domain, you can use cookies and/or local storage as a sharing mechanism.

Unfortunately the iframe is a security requirement, so they are here to stay. Thanks for your good questions. They help us see pain points and work on solutions. John

[d-molkentin]

Hi John,

thanks a lot for your detailed reply.

We will try to reduce the data we get to information we actually need. If we come up with further performance improvement suggestios, I come back to you.

Daniel

[johnDance]

@d-molkentin In 2022.2 we have dramatically improved the speed of initializeAsyc.

In fixing an issue with DashboardLayoutChangedEvent, we found that we could improve the speed of the DashboardLayoutChangedEvent, but more than this, and more importantly, we found that we could improve the speed of initializeAsync. While not noticeable on very simple dashboards, you might have noticed that on complicated dashboards there is a lag when initializeAsync is called. For 2022.2, we have improved speed of initializeAsync by 100x. You read that right. This is not 100 percent, it is 100 times faster. This will have positive impact to customers with complicated dashboards, and in scenarios such as reported here.

You do not need to do anything different to take advantage of the speed increase. John

[d-molkentin]

@johnDance Great to hear that. Thanks a lot for informing me about that! We will inform our extension customers who had issues with the performance about this improvement.