Performance degradation when upgrading v11.0p_2017-01-10 to v11.0p_2017-06-24

[nitroamos]

Hello Isomorphic,

I'm finally done with all my features, so I'd like to upgrade to your latest code before deploying because you've got at least one bug-fix for me to incorporate:

-isc.version = "v11.0p_2017-01-10/LGPL Deployment";
-isc.versionNumber = "v11.0p_2017-01-10";
-isc.buildDate = "2017-01-10";
+isc.version = "v11.0p_2017-06-24/LGPL Deployment";
+isc.versionNumber = "v11.0p_2017-06-24";
+isc.buildDate = "2017-06-24";


Unfortunately, I'm seeing a significant performance degradation. What I've got is basically a ListGrid with very heavy expansion components. Opening an expansion component used to take about 3 seconds and now it takes 10 (see attached logs). Yes, I'm sure many would regard 3 seconds as unacceptable too, but for what I get, I think that's worth it (although suggestions are welcome). The only difference in those logs is the version of Isomorphic I'm using. All I've done for those logs is to move draw and redraw to info level messages and then I copy/pasted them into the attachments.

Here's a high-level overview of my code:

              
    width:"100%",
    headerHeight: 35,
    autoFitData: "vertical",
    alternateRecordStyles:true,
    canResizeFields: true,
    canEdit: true,
    editEvent: "click",
    editByCell: true,
    minHeight:10,
    canRemoveRecords:true,
    canExpandRecords: true,
    autoFitFieldWidths: true,
    autoFitWidthApproach: "both",
    modalEditing: true,
    autoFitExpandField: "additionalPurificationInfo",
    selectionType:"multiple",
...
        table.getExpansionComponent = function(record) {
            if(record.expansionComponent){
                return record.expansionComponent;
            }
            ...

The time is not being spent in my method getExpansionComponent method because I programmatically call it ahead of time so that it's constructed and the method just returns the VLayout.

I've attached screenshots of Chrome profile info if they're helpful.

Do you have suggestions for how to narrow down what the problem is? e.g., were there specific releases of your code from the last 5mo I could check or should I jump into a binary search? Particular parameter variants to try?

Thanks,
Amos.

[nitroamos]

Oh, and one of the screenshots there shows an exception -- ignore it. That's just a broken image link that I haven't bothered to address.

[Isomorphic]

This is very little to go on, but, both the new and old logs show what appears to be a ListGrid being resized many times in the course of an initial render. It's likely that you have issues in your code that are causing this problem, and while the problem got worse with the new framework version, we suspect that if you fix the problem, both framework versions will end up performing similarly, and both will be faster than the performance you currently have with the older version.

We have zero information about the component involved, but as an example of how you can create a lot of unnecessary resizing like this, you might place a ListGrid in a Layout, allow the Layout to draw, then manipulate either the size of the Layout or add new members to the Layout (thus causing the grid to shrink). Another example would be allowing any component to draw, and *then* calling a series of setters on it which will cause it to adjust sizes of it's interior components.

If that doesn't seem like something you're doing, you can try to get a handle on where the resizes are common from by turning on the "resizes" log, and by using Log.traceLogMessage() to get stack traces when specific messages are logged.

[nitroamos]

Hi Isomorphic, thank you for your insights. I did some digging along the lines you were describing, and I don't see my code in any of the traces over the timing window. That is, I think that all of my isc objects are constructed beforehand, but then it takes 10 seconds from the moment the expansion triangle is clicked. I removed from the expansion a couple widgets that seem ok, and reduced it to one particular ListGrid which takes most of the time, which itself has a ListGrid in each row. See the attached image. I know I'm not going to win any prizes for UI/UX with this, but it's the best way I could find to display this much data where each row has different columns.



The inner tables are constructed like this:

    width:"100%",
    canEdit: true,
    canRemoveRecords: false,
    autoFitFieldWidths: true,
    autoFitWidthApproach: "both",
    autoFitData: "both",
    autoFitExpandField:"desc",
    minHeight:80,
    defaultHeight:80,
    headerHeight: 45,
    headerSpanHeight:15,
    canMultiSort: false,
    canSort: false,
    canGroupBy: false

and the outer table is constructed like this (and it's intended to display every row w/o a scrollbar):

            width:"100%",
            headerHeight: 30,
            canEdit: true,
            canRemoveRecords: !this.specSheet,
            autoFitFieldWidths: false,
            autoFitWidthApproach: "both",
            autoFitData: "vertical",
            autoFitExpandField:"Steps",
            showRecordComponents: true,
            showRecordComponentsByCell: true,
            canFreezeFields: false,//seems to be buggy w/ the step table
            canPickFields:true,
            canResizeFields:true,
            canReorderRecords:true,
            canMultiSort: false,
            canSort: false,
            canGroupBy: false,
            alternateRecordStyles:false,
            createRecordComponent : function (record, colNum) {...}
            getDefaultFieldWidth: function(field){...}

If I comment out all the autofit fields (and add in explicit heights) then my timing goes from about 5 seconds (on a simplified widget) down to a little less than 2 seconds. However, I don't want to git up autoFit.


I know I'm not giving you much to work with here... but any advice is appreciated!

Thanks!

[Isomorphic]

It's possible you've found some kind of performance loss related to simultaneously setting autoFitFieldWidths and autoFitData, but this is still too little for us to go on. We'd suggest working toward a test case: keep removing elements and simplifying things until you see the large difference in redraws disappear, then let us know what you've found; that might be enough, or we might need a full test case.

[nitroamos]

Hello Isomorphic,

Here's a test case. When I run it in my browser, the time printed to the console is about 1.3 seconds (osx 10.12, chrome 58, 2015 macbook, Tahoe skin). When I run a comparable version of my real code, I get about 1.7 seconds (I didn't bother incorporating all my custom FormItems or make sure I had the same number or kind of fields). 1.7 seconds is not as bad as the 10 seconds, but I did upgrade to 11.1, so maybe that helped (although re-running in 11.0 was not 10 seconds anymore either).


It seems like css plays a big role here... I found that by commenting out some of my CSS, the time the expansion took to draw cut down by about half. In order to provide you with a controlled test, I pasted this code in one of your showcase example editors ("v11.1p_2017-06-30/AllModules Development Only"), I see a timing of ~2 seconds.


Anyway, I don't know if 2 seconds is significant enough for you to care about, but I am curious what you think.

Thanks,
Amos.

[nitroamos]

For whatever it's worth, I tracked down the css issue I mentioned. I discovered that this:

table {
    border-collapse: collapse;
}

is significantly faster than the default:

table {
    border-collapse: separate;
}

however, if I use collapse, the auto-fitting doesn't work right (I'm getting undesired scrollbars).

[Isomorphic]

We haven't investigated your sample code in depth, but we've made a change to the handling of grid components in SC 11.0p and newer releases, which should be in the builds dated 2017-07-06 and beyond, that may affect performance. You should check whether this addresses the issue you reported.

[nitroamos]

I just tried the example I attached in your showcase with the latest version ("v11.1p_2017-07-09/AllModules Development Only") and it looks like there's been a big improvement. I now measure about 0.6 seconds on Chrome 59 on macOS (vs ~2 seconds previously). I also measured IE11 (using vmware) since it's an important target for me, and I measure about 2.7 seconds (I didn't measure IE11 before, so I don't have an easy way to compare that). Thanks!

Do you think you're likely to make any further improvements here soon? I'll need to talk to my customers and see if that's so long that they want a spinner or for me to not auto-fit stuff.

[Isomorphic]

The performance boost you saw was the result of fixing a bug in an area of code that affected the layout of grid components. We're not aware of any other similar pending issues.

If you want us to investigate a specific area of performance that we don't feel needs to be addressed now, you may have to pay for Feature Sponsorship or Support.