Speed issues with nightly 20180615

[edulid]

Hi Isomorphic ,

if I run my app with the nightly 20180604 it runs in 2 secs. If I run the exact same code with the nightly 20180615 it takes 16 seconds. So something happened between those two versions.
I started to investigate what, and I have narrowed the code to a method. This method took as I said 2 seconds with the old nightly, with the new one 16 seconds.
Here my output before and after the method:

12:59:02.309:XRP4:WARN:Log:Zeitmessung: 1
12:59:02.309:XRP4:WARN:Log:Number of records: 334
12:59:18.730:XRP4:WARN:Log:Zeitmessung: 2

This method has the following characteristics:
- It is a client method
- It does not call the server in any way, so it is client-only.
- It receives an array of Records (in this with case 334 records) and for each record it creates a FormItem. The characteristics of the specific FormItem are included in the Record as simple attributes. E.g. if it is a TextItem, ComboBoxItem, etc.
- For each FormItem created, a DynamicForm is created and the FormItem (and only one FormItem) is included. The DynamicForm has an absolute formLayoutType.

I tested deleting some kinds of FormItem creations, and it gets "faster and faster". For example, if I delete the creation of TextItems, instead of 16 secs the method needs 13 secs.

So I think something changed between these two nighlies regarded to the creation of FormItems. Could you please check the changes between these two nightlies for any hints ?

Thanks,
edulid

(using smartgwt 6.1p power)

[Isomorphic]

It's great that you were able to provide a narrow date range like that, and you'd think that would lead right to the problem, but unfortunately, we don't see any changes that could plausibly create a slowdown in form creation or initial draw. There were some changes around criteria handling, but that doesn't seem related to your report.

If you use the built-in profiling tools in Chrome (or whichever browser) are there methods where a lot more time seems to be spent in the new version?

[edulid]

Hi Isomorphic

thanks for your quick answer.
Where is it possible to measure the time spent inside methods in the chrome profiling tool? Maybe you can please show me some screenshot/link showing more information on this?

Thanks,
edulid

[Isomorphic]

? If you just use the profiler at all, it gives this kind of information. That's what a profiler does.

[edulid]

Hi Isomorphic

I tested further and I narrowed the nightly to:
20180612: fast
20180613: slow
so something has happened with this nightly 20180613. Maybe you have some hints using this narrowed range ?

I will look into the profiler and post here when I get some information. Sorry for that, I have used other tabs/functions of the chrome developers tools, but not yet the profiler.

[edulid]

Hi Isomorphic ,

it seems to be valuesManager.addMember in the 20180613 nightly. Please check these screenshots of the 13th nightly:

[edulid]

Further, the it seems not to be a painting issue as I first thought, but a scripting issue, which seems to be valuesManager.addMember() in the 20180613 nightly, as shown in my previous post.

[edulid]

Hi Isomorphic
do you have any update on this issue ?

Best regards,
edulid

[Isomorphic]

We plan on committing a fix for this today.

[Isomorphic]

Those profiles seem to indicate that you must have a huge number of fields in a client-only DataSource attached to the forms. Is that true? Otherwise the performance profile indicated doesn't seem possible. Can you modify one of our Showcase samples to reproduce this behavior?

We can attempt to mitigate the impact of the recent change regardless, but we'd like to understand exactly how it crops up in your situation.

[edulid]

Hi Isomorphic

thank you for your answer.

"We can attempt to mitigate the impact of the recent change regardless," -> What was the recent change that caused this ? What happened during this nightly release?

No, I don't have a huge number of fields in a client-only datasource. I counted them and I have 156 fields. I am not sure if this is a "huge number of fields". The fields are separated visually by Tabs in a TabSet.
These fields are included into a 156 1-field DynamicForms. So I have 156 fields and 156 DynamicForms, each with one field each. Depending on the field type, the forms use either my first or my second ValuesManager. I only have 2 ValuesManagers. Both ValuesManagers use an SQL datasource (datasource1 and datasource2). Both DataSources are *not* client-only.

I can try to create a testcase reproducing this behavior. But I would first prefer to try to investigate the behavior with my current code. I already narrowed my code as much as possible. To create a completely new testcase is not very straightforward in this case. That's why I tried to narrow as much as possible the problem to one day (nightly 13).

Best regards,
edulid

[Isomorphic]

We've made some improvements to ValuesManager.addMember() and DynamicForm.valuesHaveChanged() that should address the regression affecting you. For SGWT 6.1p/SC 11.1p and newer releases, today's builds (refreshed about an hour ago) should include those changes. For the remaining releases back to SGWT 5.1p/SC 10.1p, they'll get picked up by tomorrow's builds.

It's still not clear why your performance profile indicated such time spent in Array.find() though you only had 150 or so fields. In our testing, there was not much of an issue until the field count passed 1000. So we'd still like some way to reproduce your issue so we can analyze what exactly was happening.