Perspective Table performance and feedback

I wanted to give some feedback regarding table performance, and hopefully expedite performance improvements, if possible. We’re on version 8.0.12.

We are using a table that currently has a little over 1000 rows with 55 columns each (many of which aren’t visible to the user, but are used for color-coding values in the table). The table in question is powered by a query and a script transform. According to measurements, it takes at most 0.15 seconds for the query to run and 0.40 seconds for the script transform to finish. This is all well and good. However, we’re running into some performance issues that have been very off-putting for our customers.

  • It takes way too long to display the data–anywhere from 8 to 12 seconds for that data to actually render on the table once the query and binding finish running. During this time, the table displays an error icon with “Empty Data Source,” leading the user to believe something has gone wrong even though it’s still loading. This is a make-or-break issue for us and one of our major customers.

  • Once data begins to render after that long delay, the table is slow or non-responsive for another 2-5 seconds, another point of frustration.

  • On the Perspective app, attempting to load this table results in crashing (unless we filter it down to have less results prior to navigating to it).

  • The table causes frequent binding editor and page crashes in the designer, meaning I have to filter it down prior to loading it up if I want to even look at it.

I am able to replicate all of these problems by creating a new view and table and loading it up with static JSON data with the same size as noted before (~1000 rows, ~50 columns each, all columns have either blank styles or a different ‘color’ to change the color of the text as well).

All in all, we’re frustrated with our large tables right now. We’re doing some workarounds to auto-filter the data to avoid these issues, but if the filters are reset and the whole data set comes back, the problems present themselves again. We would be very appreciative for a response and a timeframe we could go back to our customers with.

Thanks for your time!


8.0.13 contains performance improvements that will likely shave 3-6 seconds off what you’re seeing. Try that and we can go from there.

1 Like

It does indeed look like it’s performing better, just about as you described. It’s a great start, but there’s still the issues of crashing on mobile and in the designer.

Is it safe to say there will be more performance improvements in the future (regarding tables), or is it about as good as it will get?

(Also aside, it looks like the nightly build changed the font of the launched project to Arial and removed boldness. Any way to get back to the original font?)

Thanks a ton for the reply!

1 Like

That’s good to hear. We are always working towards improving performance, but it’s a bit of a cycle, between bug fixes, new features, and memory and performance enhancements. Currently part of the team is targeting overall performance, hence these recent improvements. Suggestions for what you could consider right now on your end to possibly improve performance are:

  • Try setting the loading mode of your view and possibly others to blocking
  • Try setting the data to persistent, if it isn’t already
  • If loading is set to async, it’s possible that the updating of properties of already loaded views could hinder the loading performance of other views
  • Remove any gauge components, or update them less frequently. Less frequent updates and less components in general if at all possible.
  • If in the tables data a row or cell does not need to be a custom object, don’t make it one. Custom objects require additional processing.
  • Consider splitting the amount of data provided to the table up in some way

Close, it’s not Arial, but Noto-Sans. I’m no font expert though, so it’s hard for me to tell the difference. You can try including Roboto through theming. It’s fairly simple. I will post something a little later in the theming thread since this question has been brought up a lot.

To address your specific question about boldness. Use a font-weight of 700. That should get you what you need.