I've been further fiddling with the program I talked about HERE.
This time I took a critical look at a bunch of C preprocessor macros I wrote back in the early 1990's. The problem with macros of course is that they get expanded into something. That "something" winds up getting slathered throughout the code and if not carefully considered can result in substantial code bloat. In this case I wrote about 10 new lines of code, twiddled the macros a bit and saw the size of the test suite plunge by about 4K. That's a pretty tidy reduction for a whole 10 LOC worth of new code.
It takes a pretty smart compiler to factor all the replicated junk out and pull it into an internally generated function -- and even then its only going to happen if you've chosen some aggressive space optimization options. Many compilers aren't all that aggressive about space optimizations to begin with because compiler reviewers and benchmarks focus mainly on speed rather than generated code size and often think they're smarter than YOU the programmer are and do things behind your back to actively subvert you if you do happen to want smaller rather than faster code.
4 comments:
Its mostly a hobby now with me.
I enjoy hacking on stuff like the Linux kernel and device drivers, and laughing heartily at some of the code GCC generates. You might call that stuff a target rich environment ;->
I spent 10 years of my career at IBM doing a test (and performance) work. Some of this stuff around these days is flat out amateur.
This is in part a consequence of the collapse of memory prices, and in about equal part a consequence of the collapse of programmer intelligence.
Abot fifteen years ago I shrank a Motorola 68030 assembler program from over 3 Meg to under 6K by replacing all the macros with subroutine calls. Took about 15 minutes. The original authors, who'd been weeping piteously over their inability to get their program to download onto their MVME-147 board in under an hour (RS-232 download at 9600 baud), hailed me as a genius. I just smiled and went back to work.
The day after, I showed them how to download via EtherNet using TFTP. Download time went from over an hour to three seconds in just two days. Imagine that.
"You young folks don't know how lucky you are. Why, when I was your age, a byte had only two bits -- and they were both ones!" -- Me
And to think that I was looked on with suspicion and horror in some of my classes because I coded the assignments in C as well as I coded them in Java... Man... some of the trash that people would write in C and call code. Here's an example:
Prof told us to write a C app to test our grasp of basic C libraries and syntax that would read a file and split it into three log files. One for letters, one for numbers, one for everything else. I did mine in something like 15 lines of code using the ctype library. Then, I looked on in horror as people turned in 2 full pages of code! WTF?!
I'm glad that I'm out of there now and have been working full time now for almost a year...
Blue Cross/Blue shield in Jacksonville had an application (for their field desktops) that had to be updated daily by their programming staff due to constantly changing insurance plans, laws, doctor rosters, etc.
Build time was about 4 hours on some Unix box and the programmers were whining that this was causing them to always get home at 7pm because the changes for the day were finalized around 3pm in the afternoon and they couldn't leave until the build completed without being busted (yea, they shipped untested changes out to the field, but that's another story...)
I took a look at their build process (took about 15 minutes), and replaced a few lines in some Unix shell script with a 10 line C program that had the same semantics. Build times dropped to a much more acceptable 20 minutes the next day ;->
I was just a hired gun working on something else there. This was just an amusing diversion for me.
I never questioned why their whole programming staff couldn't figure out over the course of some years what I did in 15 minutes ;->
Post a Comment