Huge speed difference between modern and classic

[TedP]

We have a report that is showing huge speed differences between classic(flash) and modern(html5). This result is independent of browser. There are two sticking points in our report. First is on initial page load and second is when a second table is linked and filtered through an interaction from one section to another. On classic there is very little lag for these events. On modern there is a huge lag of 30 seconds or more. Strangely, the lag disappears immediately after the first load/interaction on modern and the lag difference is negligible between the two versions.

We prefer the modern view but find the inital load/interaction times unacceptable. We have somewhat alleviated the first initial page load problem by prefiltering the data (which is 4 million rows). The interaction filters another 4 million row table. 

So this leaves me with three questions.

1. How can classic be so much faster for the same events?

2. Why does the lag immediately dissapear after first load/interaction?

3. How can I get the first load/interaction to load fast in modern?

[SASKiwi]

This SAS note looks relevant:

http://support.sas.com/kb/56/431.html

[ballardw]

A very generic "reason" why a second operation runs much faster is quite often a matter of caching the data. Once all or part of data, an image, a template or othe object is loaded your computer tends to keep that in memory in case it is needed again. Hence instructions about "clear the cache" when some things don't work as a program is keeping an old version around and isn't using the latest.

This is not just between "modern" and "classic" but a performance issue in general.

[PeterWijers]

Hi ted,

I discused this problem with development just after 7.3 was released.

Problem was the full loading of all objects and data of all tabs while opening the report.

In clasic mode, the objects and data load while opening each tab at that time. ( spread of data load)

So modern mode (html5) starts slower, but switches faster between tabs.

They mentioned to switch the loading back to tab level. Lets see in the next release. Maybe we can set it via a setting.

lets ask them in Las Vegas.

greetings

[TedP · Accepted solution]

Looks like I found a solution to the problem and it appears to be an issue with a single object. We ended up rebuilding the 3rd section piece by peice and testing performance after each additional object added. We have a 4 milion row table that gets filtered in this interaction and I had assumed that it was this join and filtering that was the problem. I was very wrong. The report was blazing fast after adding the main objects to it (a plot and a chart).

The issue was with a single object - the button bar object. When we added this object back into the report, the report slowed to a crawl and was back to 30s load times. It could be that this button bar attemps to load all the variable names into the button and then filters it from there. This massive string in the button could be it.

Either way, this seems like an enormous bug.

[PeterWijers]

Hi Ted,

good to hear you have found a reason.

Just a quick question, is the filter data behind the button bar a numerical or character field.

It is a known problem that numerical fields switched to Category can lead to performance issue's.

Solution there is to load the number's as characters.

Just interested if this might be the case to cover my curiosity.

Greetings  Peter

[TedP]

Peter,

We had three button bars that were used for display(aesthetic) purposes only. They displayed three character variables that were always character variables. Looking closely upon page load (after 30s), I can see that SAS VA created many thousands of buttons (all the possible different values for our variables) before filtering them down to one button each.

We have since changed these button bars to a list table to display all three character variables and the lag completey disappeared. This seems to be an enormous bug.

[PeterWijers]

Hi,

Thanks for your reaction.

Its clear now for me.

Greetings and succes.

[AnnaBrown]

Hi TedP,

Thank you for bringing this up and providing details on your workaround. I wanted to let you know that R+D and Technical Support are aware of this issue, and are working to improve it.

Best,
Anna