Signum node phoenix wallet severe performance issues (CPU pegging)

[wolfbeast]

So today I looked at the built-in phoenix wallet inside signum node software for the first time and noticed severe performance issues related to javascript. The wallet is -extremely- slow to respond and when the tab with the wallet is active it pretty much pegs 2 cores (which indicates it's a timer-related issue somewhere). Switching the tab to the background (which throttles timers to 1 fire/second) immediately alleviates the core pegging.

Browser: Pale Moon 64-bit (http://www.palemoon.org) OS: Windows Server 2008 R2, accessed through RDP. Occurs: all the time the wallet is open in the foreground (regardless of which feature is open; dashboard, send, etc.)

Classic wallet is fine.

[wolfbeast]

I've done some more investigation, verifying the same behaviour occurring with SeaMonkey and Firefox 91 ESR. In Firefox ESR i used the inbuilt performance tools to see what's going on and as I suspected there's rapid fire timer that's causing this problem. requestAnimationFrame and setTimeout are playing leapfrog -- this seems to be caused by the polyfills library Phoenix uses. I'm not able to investigate further, myself.

See screenshot.

P.S. Some characters also do not display properly in any of the tested browsers.

[ohager]

Thanks for pointing that out.

Looking into this, I see that 80% we are idle....I also see a bunch of Layout/Style Recalculation in the call tree, which I personally think it's weird. As you are testing on more exotic browsers, I assume that your fallback is to the polyfill, which apparently has a non-native emulation of whatever it is. Actually, that polyfill js throws a single exception on Chrome and FF. I need to find out why we would need the polyfill and what it is doing. I quickly checked if some of our code has some uncleared setInterval or recursive `setTimeout, but could find anything.

[ohager]

At a first glance I tend to blame the animations polyfill. Not sure how good you are at web dev, but you might want to try to comment this import

/**
 * Web Animations `@angular/platform-browser/animations`
 * Only required if AnimationBuilder is used within the application and using IE/Edge or Safari.
 * Standard animation support in Angular DOES NOT require any polyfills (as of Angular 6.0).
 **/
import 'web-animations-js'; 

and try running the wallet on your machine, with one of the mentioned browsers you use.

[wolfbeast]

I tested on Firefox on purpose because my browser isn't mainstream (more exotic as you say) and being able to reproduce there made it clear to me that it's not really a client-side issue, which is why I dug a little deeper.

I'm... unhappy with the fact that you chose Angular. It being a Google framework is inevitably going to mean browser compatibility on anything but Chrome will suffer (severely).

As for "commenting something out" to test it -- not looking like I can do that in the burst wallet client anywhere; at least I don't see an occurrence of import 'web-animations-js'; anywhere in the \html subfolder under the signum node. Looks like everything is packed and obfuscated/minified into several megabytes of amalgamations... If there's anything I can do to test, let me know.

[ohager]

Yeah, it's all minified and bundled. What I meant is to build the wallet locally and commenting the mentioned import, that's why I asked how proficient you are with web dev. Firefox ESR is also not too common... I wasn't able to reproduce the setTimeout occurrences on common FF (Version 94), Brave or Chrome. Apparently, I need to check with one of your browsers.

[wolfbeast]

I guess we have a different definition of "web dev" ;) No I'm not at all familiar with building a framework package locally.

Firefox ESR is plenty common, by the way, but maybe not in your circles. 91.3 is the latest enterprise version of Firefox, which is what I've used to test. I'm reluctant to install 94.

[ohager]

Currently, I'm heavily revamping the apps base architecture, reducing server side requests and a more event driven approach. Hopefully, this will cover this reported issue. Still keep it open