Mar 06 2008

Chasing the cause for performance degradation

Tags: , , , , Rajiv @ 5:14 am GMT-0700

Spoiler: The last three pictures speak more than the thousand odd words that precede them

Day before:
Too many issues resizing photos in Java. Takes too much memory, takes too long, runs out of mem on Mac. A quick comparison with ImageResizer PowerToy shows that the Java code is taking too much memory and time. The difference is an order of magnitude higher on V’s machine which is slightly older and has lesser memory.
Yesterday (and day before):
Implement a photo resize server using GDI+. Go to bed happy that mem consumption is low, speed is very good and all kinks in passing around UTF-8 filenames between Java and VC++ have been ironed out.
J integrates the new resizer into the code base.
J verifies perf is 4 times better
Code is checked in … waiting for integration build
Leave for home
Receive an e-mail, integration build ready .. start downloading with the hope of gloating in the perf gains
Installation started … baby crying … unplug the laptop move closer to baby … play with the baby and complete the installation … start the test case in background
No sign of test completing … should have finished 2mins ago
Suspect some “first time” bug, run the test case again …
No luck … still pathetic perf … does not match what I saw in the morning
Pissed … shoot of a mail to J … “dood, did you checkin the integration … i see no diff in perf …
No reply … shall I wait till morn …
Let me try to recreate morning’s perf numbers … run the main method on java wrapper for the resizer … the same run which took 2mins in the morning is taking 6mins … as bad as the java resizer …damn ..
Maybe I messed up the java wrapper … run the main method on exe resizer …
Just as bad … three times slower than what it was in the morn …
11:20pm to 12:05am:
Make many runs trying to change some code in the exe … nothing seems to improve perf
Low battery alert … curse the laptop … can’t run even a few hrs without power
Make some more changes to c++ code … build … run …
By Joe! Done in 2mins instead of 6!… damn thing … why is this small change causing the whole thing to be 3 times slower … do some googling …
Undo the changes … recompile and run … see if it becomes slow again …
Thighs are burning … prop up the laptop
Hain?! Done in 2mins … WTF … it was taking 6mins just a few mins ago …
Rollback all the changes … recompile … run …
Done in two mins … WTF … How can this be … Check the logs for the timining … it was taking 6mins till a few mins ago … and the whole thing is back to 2mins now … no changes done … desperate to blame it on something … maybe anti virus was running earlier (should I check the anti virus logs?)… maybe the windows kernel has cached the files now (should I restart the laptop and see?) … maybe it became slow when i was running on battery …
Is that really possible … will my CPU run slow if it is running out of power …
Or will it be slow if it is running on battery … to save power
Hain … what a joke … laptop can’t be so smart … it was just a coincidence … I plugged in the power and it became faster …
There are no coincidences in this business … unplug the power … run the test …
No sign of ending it really is slow
Back to 6mins for the test
… can’t be … really i mean … can the laptop be so smart … what was that thing that showed clock speed … cpu-z … google: cpu-z … download … run … wow! It is true … clock speed has been reduced to 598MHz instead of 1.6GHz

OK … now connect the power and see … there goes my theory … still 598MHz

Hmmm … maybe it realized though it is powered, I am not running any CPU intensive task …. could it really really that smart … nyaaah …
Start the test with power still connected … run cpu-z … whoa! 1.6GHz …

More googling reveals, this is Intel SpeedStepTM technology at work. It can be enabled/disabled from BIOS. A quick intro at Bay Wolf. Implementation details at Intel.

Now I have to locate some java API to detect if the CPU is running at a lower clock speed so I can warn the users to power up!

Update June 05, 2008: I was wrong in suspecting my dying battery. Replacing it with a brand new one didn’t help.

Long long ago I was bugged by the fact that the screen would go blank when I was reading some content heavy websites. I opened up the power management dialog, noticed that the default power scheme used to switch off the monitor too soon when running on battery. So I decided to change the power scheme to Presentation. There is NO indication that this setting does anything other than affect: Monitor, Hard Disc and System Standby.

However, following Alexander’s suggestion when I changed the power scheme from “Presentation” to “Home/Office desktop”. I notice that the clock speed behaves the same when on battery or power: When there is no CPU intensive task, it runs on low clock speed and when there is a CPU intensive task it runs at the rated clock speed.

I wish XP warned me or atleast hinted in some fashion that the power scheme would affect the clock speed. *sigh*