| « 2.8: (Around Going) | Which Internet? » |
Wilhelm isn't really much of a smiler. Nor was he much of a laugher. Nor a crier, scowler, or high-fiver. He seemed to only be capable of two emotions: "emotionless" or "asleep."
He's of the opinion that programming has gotten too easy in recent years, not like it was back in his day when programmers were programmers. A time before garbage collectors, transactions, protected memory, fancy IDEs with fancy integrated debuggers — nowadays developers have it too easy.
One of his company's core applications had been rushed out the door with most maintenance being of the "quick patch" variety, with the intention that everything would be cleaned up later. Because of this approach the overall design of the system wasn't totally consistent — duplicate code, instance methods that should be static, classes with tons of extra properties that aren't even really used anywhere, etc. With all of the extra objects floating around in memory, OutOfMemoryExceptions were the rule rather than the, er, exception. Some of the time the errors would magically fix themselves, but with increasing frequency, a developer had to step in and restart the site to release resources.
Once it got to the point that this was happening daily, management realized the problem couldn't just be swept under the rug. When Wilhelm caught word that they'd get a chance to resolve some of the memory issues, he jumped at the chance to lead the project. He had the skillset as far as he was concerned, since he cut his teeth on Commodore 64 development where he had 64KB of memory and was happy about it. And how different could memory management be nowadays? With some competent staff and his experience with efficient memory management, he could dramatically reduce the application's memory footprint. Wilhelm was given four developers to help with the task.
First step: analysis. Wilhelm and staff prepared spreadsheets, charts, and graphs out the wazoo. Running profilers and stress testing tools they were able to identify trouble modules, unreleased resources, and unclosed connections.
Second, branching the code and tweaking algorithms, static-izing what used to be instance methods. The team worked day and night on small refinements, creeping closer and closer to their goal. Changes had a tendency to delay development, as some parameters were being set too conservatively, breaking something else down the line. Some of the developers complained, but it didn't bother Wilhelm — the sissies hadn't suffered through the hardships of programming on older hardware, and this was molding them into something closer to real programmers.
After five months of grueling optimization and fixes, the team had finished. Admirably, they had succesfully reduced the application's memory footprint by more than 50%! His team still complained about some of the work, but Wilhelm knew they'd eventually adjust to the new programming style.
So Wilhelm, known for his emotionlessness, had a huge smile on his face when he summoned everyone into the conference room for a meeting. "First the good news," he began, "The memory footprint is now 46% of what it was before." He started doling out impressive-looking packets with detailed graphs and overviews of big changes to the system. "Now if you'll all turn to the second page, I'd like to go over some of the architectural changes. Before that, though, any general questions?"
Jake C. happened to be at this meeting with a new intern named Bob. Bob raised a finger and said "Yes, I have a question — this graph shows the percentage of the memory footprint reduction, but what are the actual numbers here? How much memory is in the production server?"
"512MB," Wilhelm replied.
"Ahh, OK." Wilhelm scanned the room for more questions. Bob raised a finger again. "So why not pick up another 2GB of memory for fifty, sixty bucks and install that in the server?"
Wilhelm was taken aback. With a light stutter, he replied "Yeah, I guess that would've been an option too..." After a brief but intensely awkward pause, he continued with a quivering voice "...but no web application should ever require more than 500 megs."
Wilhelm continued with his presentation, his face a bright shade of red. His manager's face turned a similar color.
Re: That Would've Been an Option Too
2008-07-17 11:16
•
by
Wilhelm
(unregistered)
|
Oh this is easy - I'd begin a 5 month optimisation effort. |
Re: That Would've Been an Option Too
2008-07-17 11:26
•
by
halber_mensch
|
Yeah, those asshole people that waste all their time harping on "memory management" and "properly documented code" and "runtime efficiency" are always getting in the way of me playing Halo in my cube too. They're always bitching at me because my code is crashing the web servers - DUH! BUY NEW ONES YOU LAZY BUMZ0R3Z! Look, you could have called CDW in the time it took for you to whine at me. Now leave me alone so I can do some REAL work on my MySpace page. |
|
While optimizing code is all well and good, management cares about the bottom line. If the memory usage slowdown ends up being negligible after a cheap RAM upgrade you look pretty stupid for wasting time and money when a quickfix would have kept the trains on time. You say eventually that wouldn't be enough, but then maybe they buy a new server with twice that much ram for 100 bucks. You don't know for sure, and worst case they end up optimizing later but maybe they can get away with it. If the hardware is cheap, then don't blow money optimizing the software first.
I know you all live in Utopias though where it's okay to waste money on non-noticeable improvements, but the intern just pointed out that Wilhelm possibly wasted a lot of money. Results are all that matters in business. |
Re: That Would've Been an Option Too
2008-07-17 11:30
•
by
anonymous
(unregistered)
|
16k!?! I started with 3.5k on a VIC-20, thankyouverymuch. |
Re: That Would've Been an Option Too
2008-07-17 12:15
•
by
Tom
(unregistered)
|
|
As far as I can tell, the suggestion is that it wasn't leaking memory, it just needed more than 512 for what it was doing.
It's like spending hours squeezing every article of clothing into a suitcase, using complicated folding techniques, when you could just get a larger suitcase for ten bucks. If it *was* leaking, then fixing the leaks is surely more important than getting the normal running memory usage down, especially as that's likely to make your code unmaintainable. |
Re: That Would've Been an Option Too
2008-07-17 12:33
•
by
Anonymous
(unregistered)
|
|
The computer had 512MB of ram. What production computer has 512MB?
Wilhelm's solution was one of many. It was the correct way to do it from a University Computer Science department standpoint, but businesses don't operate that way. You don't sink 25 man months into problems with such an unbelievably small scope. The correct solution would have been to upgrade the production server while bug fixing the memory leaks. It just got taken too far. No suprise from a company that would let this happen in the first place. Wilhelm was the team leader but still an unfortunate player in all of this. The responsiblity of failure wasn't on his shoulders but on the management of said company. This should have never happened. |
Re: That Would've Been an Option Too
2008-07-17 12:48
•
by
Fedaykin
(unregistered)
|
|
Sorry, but the WTF would be just throwing more memory at the problem, because all that would do is make the time between OOM errors longer. It wouldn't solve the core problem of poor resource management in the system.
Now, from TFA, I would guess there is a big chance that the effort was way overboard, but the core intent was correct: fix the source of the problem. Throwing more memory at the problem is only yet another duct tape and chicken wire solution. |
Re: That Would've Been an Option Too
2008-07-18 11:25
•
by
Rumblefish
|
Pontoons. All you need are pontoons. |
Re: That Would've Been an Option Too
2008-07-18 12:30
•
by
Rumblefish
|
Ahh, but there are. In a number of poorly designed systems I've seen personally, there are methods within a class that are instance methods, although they perform no function that is specific to any instance. For instance (no pun intended), if you have a DateTime class that defines a "getCurrentDateTimeAsString()" method that retrieves the system's current date and time, you would be best off defining that as a static method because the system's date and time should be the same across all instances, thereby not require instantiation to be properly functional. But I've see numerous situations where, for some reason apparently known only to the developer, a method like that was defined as an instance method. |
| « 2.8: (Around Going) | Which Internet? » |