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

Originally Posted by 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

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

Originally Posted by Andy 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.

Originally Posted by Allen 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.

Originally Posted by Andy 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/Bird...1594251_tgXdV3

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?

Originally Posted by 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?

ff 13.0.1

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.

Originally Posted by 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.

Not tried any other browser.

Originally Posted by Allen Not tried any other browser.

Please do.

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

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

Originally Posted by SamirD 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.

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'.

Originally Posted by SamirD 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.

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.