CPU usage on local machine when editing reports

[briancole]

Hi,

I'm on Analytics 11.1.2 on a hosted environment (just upgraded from 10.2.2) and have noticed that editing reports gives a very sluggish user experience for the developer which is very frustrating. Even just changing the focus to select an object has a very noticeable lag of 4-5 seconds. The report I have opened has a lot of objects in it, but Report Studio handled this no problem before.

I've noticed CPU usage rockets when I do this (~70%). I am on a Dell XPS 13 laptop so processing power\RAM isn't an issue.

I've tried using IE11 and Edge, but the issue is the same. Has anyone else experienced this? Are there some local IE\Edge settings I need to implement?

Thanks in advance for any help you can provide.

[briancole]

Hi,

I've done some more digging on this and noticed that if I use chrome, the interface is lightning-fast. Unfortunately Chrome is not a supported browser in my organisation, so I can't just move everyone over to it. I know I'm clutching at straws, but I'm hoping that there might be a setting to enable\disable either in IE or Java to speed things up somehow?

[BigChris]

Interesting. I realise this is of no use at all, but I use IE by default and it's pretty zippy. I've found that a few things aren't available in Chrome, otherwise I'd be using that...but only for preference and not for speed.

[briancole]

That's very interesting. I've mainly noticed it when I've got reports with a lot of content open for editing, but for me, even just moving my mouse over items in the Team Content view has a noticeable delay. The delay seems more prominent when you stop moving the mouse for a second, and then move to another item and there's a significant lag. This becomes more prominent when editing reports as this is a behaviour you would repeat a lot.

Out of curiosity, what version of IE are you using?

I've done some performance profiling and it seems that it's DOM events which are particularly slow. I've also noticed that any JavaScript functions that we've written to loop through the DOM are also now performing terribly, so the two things are likely linked. A quick google search is returning historic problems with IE and DOM manipulation, but unfortunately this doesn't help me get to a resolution   :(