High CPU Usage

Allen

What gives, I go into the new (forced on us) price settings page, expand the products
and I get 100% CPU usage? No other apps running except Thunderbird sitting idle.
Think Smug needs to tone it down some.
Intel Core 2Quad CPU Q8300 @ 2.50GHz 2.50 GHz
WIN7 64bit
6 GB RAM

Andy

Allen wrote: »

What gives, I go into the new (forced on us) price settings page, expand the products
and I get 100% CPU usage? No other apps running except Thunderbird sitting idle.
Think Smug needs to tone it down some.
Intel Core 2Quad CPU Q8300 @ 2.50GHz 2.50 GHz
WIN7 64bit
6 GB RAM

Al, give me a direct link to the page in question please?

Allen

Andy wrote: »

Al, give me a direct link to the page in question please?

Tools > set prices > default > edit prices > click products to expand
reproduced although I did not get the High CPU Use warning this time.

Andy

Allen wrote: »

Tools > set prices > default > edit prices > click products to expand
reproduced although I did not get the High CPU Use warning this time.

I need the precise link to the gallery you were doing this in, Al. Link please.

Allen

Andy wrote: »

I need the precise link to the gallery you were doing this in, Al. Link please.

I just did it in another gallery. That's three different galleries. It jumps when expanding products for
about 10 sec. then settles down. Can then expand/collapse and only might spike occasionally at ~50%.
What allerted me was the Norton "High CPU Usage" box that popped up.

manage price lists > default > edit]

Last gallery tested
http://www.photosbyat.com/Birds/Birding-2012-February/2012-02-22-Eastern-Shore/21594251_tgXdV3

Andy

OK I'm not seeing anything like what you're seeing
I'll ask around. Can you try running from a reboot, and NOTHING else but your browser (btw, which browser and version?) and doing it?

Allen

andy wrote: »

ok i'm not seeing anything like what you're seeing
i'll ask around. Can you try running from a reboot, and nothing else but your browser (btw, which browser and version?) and doing it?

ff 13.0.1

SamirD

Does this do it in just this browser or in Chrome or others as well. It could be just the way FF interprets that piece of code.

Allen

SamirD wrote: »

Does this do it in just this browser or in Chrome or others as well. It could be just the way FF interprets that piece of code.

Not tried any other browser.

Andy

Allen wrote: »

Not tried any other browser.

Please do.

Allen

Tried IE9 and the CPU sporadically spiked between 30-70 but it never got close to 100%. So maybe only FF.

SamirD

All the browsers interpret the code differently, so some browsers may work better than others for certain sites.

jfriend

SamirD wrote: »

All the browsers interpret the code differently, so some browsers may work better than others for certain sites.

Javascript code that runs poorly in some browsers is Javascript code that needs fixing. I would not blame this on the browser. I would blame this on the javascript code that's causing the problem.

SamirD

But since javascript is interpreted, isn't it the fault of that brower's particular interpretation?

From a practical point-of-view I agree because it affects the end-user experience. It's basically like SM having to patch around the quirks in IE. I never thought FF would become 'that browser'.

jfriend

SamirD wrote: »

But since javascript is interpreted, isn't it the fault of that brower's particular interpretation?

No. Whatever issue causes this, it most likely won't be because of a bug in the actual javascript engine itself. It's more likely a piece of code that just doesn't perform very well on some browsers. That could either be due to the speed differences between the javascript interpreters or more likely a speed difference in some of the function calls the javascript code is making or a difference in timing of some events.

For example, I've seen poorly written code that doesn't work well when the browser window is resized in some browsers because the code performs poorly in some browsers and those browser flood the queue with resize events. A fairly simple change to the code fixes the problem entirely by making sure that resize events don't queue up and the resize code only executes when the user pauses their resize. Is that a browser or javascript interpret bug? No. That's understanding the execution environment of your target browsers and writing code to handle the situation properly.

Of course, I have no idea what the issue in this case, but I was just giving you an example.

SamirD

Thank you for the clarifcation. Always great to learn new things about what's going on under the hood. No idea that you could even queue instructions like that.