[pH4Lk0n]

Hi,

3. About this suggestion again.
I'm testing with my real life example which have a handler with multiple calculation and field updates with setValue().

Without whenRules it's working just fine and takes around 15-20ms to run - this is without FormIf functions that was replaces with whenRules.

With whenRules enabled it takes more than 500ms. It's after fix with (String)null so no recursive processRules calls but still it's called 54 times and takes a lot of time. On testing machines it takes a lot more.

I've created a simple proof of concept.

isc.RulesEngine.addProperties({
    processRules : function (rules, component) {
        console.log("processRules", component.ID, rules);
        if (!this.processRulesTimeout) {
            this.processRulesTimeout = {};
        }
        if (this.processRulesTimeout[component.ID]) {
            clearInterval(this.processRulesTimeout[component.ID]);
        }
        this.processRulesTimeout[component.ID] = setTimeout(() => {
            this.processRules2(rules, component);
        }, 0);
    }
});

And in processRules2 method is original code of processRules.
Now same scenario runs in about 20-25ms and original processRules are called only 2 times.

I now this code is plain simple but it's just a proof of concept and maybe there are some caveat's that I'm not aware of but considering huge performance boost I think it's worth looking at.

Best regards
Mariusz Goch

[Isomorphic]

Thank you for your work on this test case. Regarding the typecast lines, we are not reproducing a performance difference, or really any performance problem, with your test case.

Is it possible this was not tested with a build that has the first round of optimizations?

Or was your intent here not to reproduce a performance problem per se, but just show what appear to be redundant processRules calls?

[pH4Lk0n]

Ok. You've got me real thinking.
We are talking about this problem - recursive calls of processRules in particular scenario.
https://forums.smartclient.com/forum...539#post270539

It was before tested on SmartGWT 13.0p 2023-07-10.
To be sure I've updated to latest nightly: SmartGWT 13.0p 2023-07-15 and I still see this problem.
But If you don't see the problem I looked further and I'm shocked.
Found it in my skin modifications. When switch to basic Tahoe problem does not exists.
So I compared all settings and found the problem one:

isc.TextItem.addProperties({
    autoComplete: "native",
    width: formItemWidth,
    height: formItemHeight,
    showFocused: true,
    textBoxStyle: "textItemLite"
});

When you set autoComplete to "native" the bug with recursive calls appears without it it's gone.

And testing some more it's also connected to poor results in other cases.

So as I see we've got to problems:
- so slow processRule with autoComplete = native
- so many calls of processRules

So testing some more in my real life example (all tests done with SmartGWT 13.0p 2023-07-15) -of many calculations and multiple rules on a form.
1. With autoComplete = native: around 250ms
2. Without autoComplete native: 40ms
3. Adding patch to minimize calls of processRules: 10-15ms

So the problem with autoComplete is not only connected to recursive calls. In above example I also checked and there are no recursive calls.
But this change significantly affects processRules single call which I observed in profiles. From around 25-40ms for one call it dropped to 2ms.

Hope this help solving both problems.

Best regards
Mariusz Goch

[Isomorphic]

Wow! Nice job figuring this out. We were already working on further eliminating the recursive calls, but this autoComplete:"native" thing is definitely a separate problem, and we'll check it out.

[pH4Lk0n]

Hi,
Any news on this problem?

Best regards
Mariusz Goch

[Isomorphic]

Hi pH4Lk0n
A quick update on this issue:
The bulk of the slowness here is GWT specific. The performance problems go away with equivalent code written in pure SmartClient/JS.
We are still investigating this (and pinning down / resolving the cause of the slowness in GWT may still take some time).

However there are some changes we can make in the SmartClient framework code which should have a huge impact on this issue.
These are in progress and we'll be following up here when they're in place

Regards
Isomorphic software

[Isomorphic]

We've now made these optimizations in the framework source and in our testing they resolve the slowness in the test case you shared.
Please try the next nightly SGWT build - 13.0 or 13.1 branch, dated Sep 20 or above and let us know if this continues to be a problem for you

Thanks
Isomorphic Software

[pH4Lk0n]

Hi,

Thank's for update.
I've checked my test cases and I see huge performance improvement.
Now I don't see much of a difference between test with and without whenRules.

Tests in real life example also doesn't show any performance problems. Even though I've also increased use of when rules.

I will perform more test's but for now it looks like problem is resolved.
Thank you very much.
Best regards

Mariusz Goch