Slow opening of folders in TreeGrid?

[user316]

Hello,

We have a TreeGrid with lots of records, and the opening of folders is quite slow (over 1 second). Could you please look into why this is? I suspect it is something in the framework code that needs to be optimized. I don't think it is drawing-related slowness, because even if every folder is collapsed, and I open a single top-level folder, there is a lot of lag. Perhaps in the framework code you have loops within loops, or something of the sort?

I have attached source code of an example. You will also need to download a 3 MB source file from here which contains the records: https://we.tl/t-O9n2DnB0iV
I could not attach this into the forum thread since there is a 2 MB limit. Note that the link expires in 7 days.

Also by the way, near the end of BuiltInDS.java, there are lots of options for the TreeGrid example which I have set because in the actual code we set these options as well. However, when these options are disabled, the folder opening is still pretty slow.

[Isomorphic]

Did you actually build and run the sample? What version of GWT did you use? We're getting a "constant string too long" error from javac in the JsonExampleB.java file.

[user316]

Yes, it builds and runs for me using Eclipse. My version is: SmartClient Version: SNAPSHOT_v12.1d_2019-07-10/PowerEdition Deployment (built 2019-07-10)

[user316]

I have created a new version of the example. This one downloads the json data using an RPCRequest, instead of hard-coding the json into the .java file, so that it will be easier to compile. Please see attached.

Also please download this text file: https://we.tl/t-rjNeAfP1Rc (JsonTreeGridRecords.txt, 2.5 MB). It needs to go into the /war directory of the SmartGWT project.

[Isomorphic]

Yes, it builds and runs for me using Eclipse. My version is: SmartClient Version: SNAPSHOT_v12.1d_2019-07-10/PowerEdition Deployment (built 2019-07-10)

That's good information, but we were asking about the GWT version, not the SGWT version.

[user316]

That's good information, but we were asking about the GWT version, not the SGWT version.

It's GWT 2.8.2.

[Isomorphic]

We see that much of the overhead is related to using autoFitData :"both". Are you sure you need this approach, especially vertically? The ListGrid will automatically show a vertical scrollbar, as needed, to provide access to rows that exceed the vertical space. Also, in your sample code, the overflow:"hidden" settings you're applying to the grid and gridBody appear to be clipping some of the columns so they can't be seen.

[user316]

Thanks for you help, disabling Autofit did improve the speed. I also removed the overflow:hidden settings, although those weren't an issue in the deployed code since there was a scrollbar.

I noticed that with the disabled autofit, there is still some noticeable delay when opening the folders (perhaps 200 - 500ms). Do you know if it can be made even faster? Is it mostly a drawing delay, or is it the logic figuring out which records to draw?

[Isomorphic]

We've made some improvements to speed up folder toggling in your original sample (with autoFitData:"both"). With the fixes in place, we're seeing times in the 600-700ms range. These have been committed only to SGWT/SC 12.1d since you indicated that's the branch you're using, and will be available in the nightly builds dated 2019-10-27 and beyond. There is an additional optimization we can pursue related to autoFitData, but it sounds like you may be pursuing a different approach.

One note when analyzing the browser profile (assuming that's what you're doing). The reported work (non-idle time) is not an accurate reflection of latency. Instead, look at the timeline and measure from the point of "mouseUp" until CPU activity drops off (which should correspond to the last redraw() completing).

With autoFitData: "none" and the default overflow settings on both the ListGrid and GridBody (as you indicate), performance is indeed much better and you should also notice the scrollbars have a more consistent appearance. For added speed, you may also want to set animateFolders:false if you can tolerate it. With that configuration, we're seeing consistent times in the 200-300ms range for folder toggling. Users should generally find this timing "responsive." It's not clear that there's any "low hanging fruit" in this path available for easy optimization. In our code, that time is spent retrieving the cells to be drawn, formatting them as HTML, etc.