|
Concerned about upgrading to
SQL Server 2005?
Get insider advice on the risks and benefits, and learn the best practice strategies
to plan for a successful upgrade to SQL Server 2005.
The Microsoft Gold Certified experts at Edgewood
Solutions provide the ultimate array of SQL Server database administration
and development solutions for upgrades, data protection and optimization.
Get a free needs analysis or download the SQL
2005 Report now. We can help! |
|
| Find
out what pitfalls to avoid.
Free Needs Analysis |
|
04.20.06
Slow Down, Simplify
 By
A.P. Lawrence
Microsoft's most recent updates apparently caused problems more than a few users: Microsoft Patch Snafu Grows, Users Seek Workaround.
My wife's XP has been running slowly since that patch, but a least it's still usable. I can probably just leave it be until Microsoft's next patch cycle. Not everyone can; some have had to back it off entirely.
A modern operating system like XP is a complicated beast. It's tempting to toss darts at Microsoft's incompetence, but while they certainly deserve some disdain, it's also true that patching often has unexpected and unpredictable effects somewhere else in the system. As the entire OS is far too complicated for any one person to grasp, these side effects are likely inevitable.
By the way, here's someone who actually likes Windows tossing some well deserved darts at Microsoft.
Anyway.. I can't help but wonder if clever code and pursuit of performance adds to this problem.
We are an impatient bunch, aren't we? We want our windows to snap open, we hate waiting for anything. While faster and faster hardware certainly feeds those desires, the OS and application folks can't ignore our demands either: they have to code for performance. A great deal of effort is put in to tight, efficient code that doesn't waste cpu cycles.
That code isn't necessarily buggy, or any more apt to be affected by seemingly unrelated patches than looser code would be, but it's almost certainly harder to understand, especially at a casual glance. So here we have a tight, fully optimized printer driver that has been working fine. We make a patch to the general printing system for some reason. There's no obvious reason to expect a problem with the driver, so probably no one even looks at it at all, but if they do, that efficient code certainly makes it harder to spot the glitch that is going to bite us later.
Sometimes the problem isn't from the programmer at all: modern compilers are fiendishly clever at optimization and will rearrange code to their own liking. A program that looks quite straightforward in its source form can be a maze of dark and twisty passages in its executable image.
But then again, sometimes the programmer is to blame. Sometimes programmers do cutesy stuff that is completely pointless. It looks clever, but the compiler would have generated equally good and equally fast code without their tricks, and the source would have been a heck of a lot easier to understand.
You aren't going to see Microsoft running an ad campaign bragging "We're better because we run more slowly", but both general security problems and plain old annoyance bugs would be lessened if code were more simple. Of course we'd also lose features, and that's impossible to accept: we need all these features.
And we need them now, thank you.
*Originally published at APLawrence.com
|
