Mar 06 2008
Chasing the cause for performance degradation
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.
- Noon:
- J integrates the new resizer into the code base.
- 2pm:
- J verifies perf is 4 times better
- 6pm:
- Code is checked in … waiting for integration build
- 8pm:
- Leave for home
- 10pm:
- Receive an e-mail, integration build ready .. start downloading with the hope of gloating in the perf gains
- 10.30pm:
- 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
- 10.35pm:
- No sign of test completing … should have finished 2mins ago
- 10.40pm:
- Suspect some “first time” bug, run the test case again …
- 10.46pm:
- No luck … still pathetic perf … does not match what I saw in the morning
- 10.50pm:
- Pissed … shoot of a mail to J … “dood, did you checkin the integration … i see no diff in perf …
- 10.55pm:
- No reply … shall I wait till morn …
- 11:00pm:
- 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 ..
- 11:10pm:
- WTF?!!
- 11:11pm:
- Maybe I messed up the java wrapper … run the main method on exe resizer …
- 11:18pm:
- 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
- 12:05am:
- Low battery alert … curse the laptop … can’t run even a few hrs without power
- 12:07am:
- Make some more changes to c++ code … build … run …
- 12:09am:
- 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 …
- 12:10am:
- Undo the changes … recompile and run … see if it becomes slow again …
- 12:09am:
- Thighs are burning … prop up the laptop
- 12:12am:
- Hain?! Done in 2mins … WTF … it was taking 6mins just a few mins ago …
- 12:15am:
- Rollback all the changes … recompile … run …
- 12:17am:
- 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 …
- 12:18am:
- Is that really possible … will my CPU run slow if it is running out of power …
- 12:18am:
- Or will it be slow if it is running on battery … to save power
- 12:19am:
- Hain … what a joke … laptop can’t be so smart … it was just a coincidence … I plugged in the power and it became faster …
- 12:19am:
- There are no coincidences in this business … unplug the power … run the test …
- 12:22am:
- No sign of ending it really is slow
- 12:25am:
- Back to 6mins for the test
- 12:25am:
- … 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
- 12:25am:
- OK … now connect the power and see … there goes my theory … still 598MHz
- 12:25am:
- Hmmm … maybe it realized though it is powered, I am not running any CPU intensive task …. could it really really that smart … nyaaah …
- 12:26am:
- 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*
Alexander Langer
May 13th, 2008
4:28 pm GMT-0700
Comment #1