Bugzilla – Bug 6625
Slow performance in new default skin
Last modified: 2009-07-31 10:16:03 UTC
"Slow" in this case is massively understating the issue, IMO. The web interface is near impossible to use - and not because the server is slow - the processor load is horrendous. Steps to reproduce (Opera and IE behave identically) in this regard: 1. Open Task Manager. 2. Select the Processes tab. 3. Sort by CPU usage (click on the CPU column - if you haven't got one, enable it) until the high numbers are at the top. 4. Load up the slimserver homepage in your browser (Opera 9 and IE 7 tested; don't have FF here to try). 5. Select the 'albums' option to list all the albums. 6. Widdle the mouse up and down over the albums list. 7. Observe as you do this that the CPU value for your browser increases until it's just around 80-95%. As you stop moving the load drops. This implies to me that for every mouse event delivered, there is some (significant amount of) processing being done. It is reinforced by the fact that as you move from one highlighted row to another it takes a moment or two for the highlight to move with you - and whilst you're waiting for it to move the CPU usage by the browser is very high. This can be seen better by increasing the update speed in taskmanager to being very high. All tests performed on a 2Ghz Sempron with XP.
tops out at 40% for me. P4 2.3G. Certainly isn't sluggish even when forcing fast highlight changes.
I see pretty much the same thing with Opera 9.25. Running 32 bit XP Pro SP2, with a dual core Athlon 64 X2, and 2GB memory, Opera peaks at 50% CPU usage, which means it's pegging one of the CPU cores. I don't have IE7 intalled here. Firefox 2.0.0.11 performs the best, using only about 60-75% as much CPU as Opera, while IE6 is somewhere between the two. Could be just the JavaScript highlighting. In Opera, browsing albums with only text displayed, moving the mouse up and down, I can see the highlighting lagging way behind the mouse cursor.
I have to admit, the interface is slower than I'd like it to be. The highlighting is using way too many resources. But it's far from "impossible to use". As long as you display a reasonable number of items per page, it should really be ok. Setting the number to 500 will definitely render the system unusable. But hey, there's a reason that parameter was introduced. You say "display all albums" - how many items would this be on one page? As long as your machine has enough resources to update the CPU graph in the task manager, we're fine :-).
(In reply to comment #3) > I have to admit, the interface is slower than I'd like it to be. The > highlighting is using way too many resources. But it's far from "impossible to > use". It's the reason I don't use it. It's unresponsive and cripplingly slow and - in my opinion - that makes it unusable. > As long as you display a reasonable number of items per page, it should > really be ok. Setting the number to 500 will definitely render the system > unusable. But hey, there's a reason that parameter was introduced. > > You say "display all albums" - how many items would this be on one page? I clicked on the 'albums' and it showed me the first set of items - "Items 1 to 52 of 4502", so 52 items on that page. > As long as your machine has enough resources to update the CPU graph in the > task manager, we're fine :-). I'm sorry, but I don't believe that's a justifiable argument in the slightest. A web-based application should not be able to soak up all of the processor time such that the display gets that high. If it does then there is something significantly wrong with the things that it's doing. Maybe I'd like the processor time for something else, and 'moving the mouse over a web browser' should not count as a machine-crippling operation.
It's not machine crippling is that's all that you are doing. A process will have a tendancy to use up as much processor power as there is available to do something as quickly as it's demanded. There are other skins, with features that don't require the browser to do as much work. That is the real option.
There is some potential for improvement. I've found a few unneeded calls. But I wouldn't expect wonders. Stay tuned.
(In reply to comment #5) > It's not machine crippling is that's all that you are doing. A process will > have a tendancy to use up as much processor power as there is available to do > something as quickly as it's demanded. There are other skins, with features > that don't require the browser to do as much work. That is the real option. You're right. That the option I should choose. I should just use the other skins and not bother reporting the real reason for not wanting to use the new skin into which so much effort has been put.
My point is that next time, you can leave out the hyperbole. It shows a bit more respect for those who have put in that effort.
change 16371 - improving highlighting code. Firebug's profiler measures a 35% performance improvement, but I can't feel it in Opera. Maybe Opera is slow in different parts of the code :-/
Wow... I just noticed that Opera would peg the CPU even if we did _nothing_ at all in the mouseover event handler! Put a return at the very top of Utils.highlight - it wouldn't change the load. So there's nothing we can do in this particular case.
(In reply to comment #8) > My point is that next time, you can leave out the hyperbole. It shows a bit > more respect for those who have put in that effort. No ta; I just won't bother reporting it next time. I avoid exaggeration in almost everything I do, because it leaves you nowhere to go when you find something worse or better. However, in this case I was not exaggerating. My opinion was that it was in fact near impossible to use. The highlights are unresponsive and the processor load is very high. I have a lot of respect for the people that wrote the code, and I'm reporting the bugs as I see them - in particular, bugs that nobody else seems to be seeing. I am very surprised at your response that the behaviour of the mouse handler, and yet more surprised that this has not been identified earlier.
Let's please stick with discussing the issue here, not personal feelings. Thanks. Did you have a chance to test the changes I did?
Justin - are you using some FF add-ins by chance? There's just been a report by a user who had Adblock installed, which caused constant CPU load. He now replaced it with Adblock Plus or something and his issues are gone. Firebug is also know to slow down the web interface. Thus I think there might be a bunch of potential fun-stoppers out there. I'd be happy to know them...
Ping Justin.
(In reply to comment #12) > Let's please stick with discussing the issue here, not personal feelings. > Thanks. > > Did you have a chance to test the changes I did? No; I've switched to the Classic skin as suggested, which has made the web interface useable. (In reply to comment #13) > Justin - are you using some FF add-ins by chance? There's just been a report by > a user who had Adblock installed, which caused constant CPU load. He now > replaced it with Adblock Plus or something and his issues are gone. > > Firebug is also know to slow down the web interface. Thus I think there might > be a bunch of potential fun-stoppers out there. I'd be happy to know them... As stated in the description, the tests were performed in Opera and IE; not in FF.
Testing with latest svn with Opera and with the Default skin; the load seems similar, the bar is a little more responsive, but still seems to lag a long way behind the mouse.
Not related to the OP's problem, but some pointers about known FF issues causing high CPU load: http://forums.slimdevices.com/showthread.php?t=40164#16
Can we consider this acceptable for 7.0?
Appears to be acceptable for most users for the first release. We'll continue to optimize as we move on to 7.0.1. Please feel free to add additional information about the experience.
we're going to review this when the update to ExtJS 2.0 and the general JS refactoring is done.
The Default skin's JS code has almost completely been rewritten for 7.1. Feel free to re-open if you think this is still an issue. Thanks.
I'm able to get CPU% up to ~60% at most using OP's reproduction steps, verified as resolved in 7.2 - 22869
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC