Change to calculateRecordSummaries logic between 10.0 and 12.0

[senordhuff]

Hi there, we are trying to complete an upgrade from 10.0 to 12.0. Unfortunately, we are running into very time consuming investigations on why our application is so much slower with 12.0. I am combing over our application nearly line by line to figure out where the bottlenecks are.

We have a grid where the user can choose between 800+ fields to display and they will typically have 10-15 different views each showing perhaps 15 fields. So, this.fields is 15 while this.getAllFields() is 800. I found this line is now different in calculateRecordSummaries()

10.0:
var fieldsToUpdate = this.fields;

12.0
var fieldsToUpdate = this.skipHiddenUserSummaryFields ? this.fields : this.getAllFields();


This is a major performance hit for our application because this.getAllFields() returns so many fields that were not being returned in 10.0. I am looking for information on skipHiddenUserSummaryFields but I don't see much in the code, in the forums, or in the docs. Can you shed any light on this property and whether we are safe to set that to true or just use the original line from 10.0 as an override? Any other suggestions on how we can speed up the process of finding these bottlenecks for a gird like ours would be helpful as this has been very slow and painful. I've noticed that sorting is significantly slower for our grid and still tracking through to figure out why.

[senordhuff]

Also wanted to point out that even though we debugged this by turning off grid and group summaries, we still see this performance hit because this check doesn't happen until the end of the method. Is it necessary to execute all of this other logic on a grid with summaries turned off?

// if we're showing neither group nor grid summaries we can bail here since the
// remaining code below is strictly dealing with group and grid summary rows.
if ((!this.isGrouped || !this.showGroupSummary) &&
(this.summaryRow == null || !this.showGridSummary))
{
return;
}

[Isomorphic]

Hi senordhuff
We have a developer taking a look at this area to see what the best approach would be to improve the efficiency for cases like yours.
One question though - we wouldn't expect a large number of hidden fields to dramatically impact performance within this subsystem unless a large number of these fields actually are user-formula or summary fields.

Can you confirm whether that is the case? If not, it might be worth showing us the pattern you're actually dealing with a little more specifically so we can be sure our assumptions about what's going on are accurate.

Thanks

[senordhuff]

Hi there, I found another issue related to logging that I just posted about. Let me go revisit this again and determine whether this was a side-effect of the other issue or not. I can tell you there are about 35 user formulas in the grid in this particular case. And, thank you for having a developer take a look. It would be good to know you have some automated tests and efficiency checks to ensure our usage is optimized. I'll try to reply more tomorrow.

[Isomorphic]

To follow up on this:
The "skipHiddenUserSummaryFields" flag is internal and unsupported, but as you noted, will suppress the work being done by calculateRecordSummaries for hidden fields.
If you need a solution urgently, you could make use of it for now.

As with any unsupported API, we can't guarantee whether this will continue to work in the future. However, we have a developer assigned to investigate this area, and we will make sure we update this thread if this particular flag does go away (or if we decide to expose and support it).

You should also be aware that if your grid has (visible) formula fields which rely on values calculated from (hidden) summary fields, these will no longer be displayed with this flag enabled.

[senordhuff]

Hi there, thanks for the follow up. Not sure exactly why but once I apply a fix for this issue reported with logging in 12.0, this performance penalty for calculateRecordSummaries is resolved?
https://forums.smartclient.com/forum...mpared-to-10-0

So, I'll wait to hear your feedback on the other thread.