October 29, 2007 at 11:06 am
I am going to start off with the summary. Management/Business requirements should determine what is the proper avenue to persue. Sometimes readability/supportablity is more important to the business than performance. It's a lot easier for a business to buy a bigger box than it is to find a good programmer 🙂
Speed vs. clarity. Hmm. I'm not sure I agree speed is always the case. FYI, I agree the case statement is the best approach here. However, I don't know I agree with in-line assembler if the ONLY reason is for speed. If it is for functional reasons, then YES, do it, but not for speed alone.
Everything is a compromise. I expect less than 1 in 10 developers know assembler these days. Probably worse than that, and mine is far from being what it was 20 years ago when there wasn't a choice. From a management perspective, I can't count on any one developer staying with my company for any period of time. If one of them writes code that no one else understands; what do I do if it breaks?
Don't misunderstand me. I will often spend a great deal of time ensuring that my code is efficient. I won't however tweak every ounce of performance out of my code unless that is the need. I recently had a need to do that and in that case writing very optimized code was needed.
I am sure that somewhere in my mind I make a decision that enough is enough, everyone has to at some point. I can honestly say that I will often lean towards more stable/maintainable code vs efficient code. For example: If I am writing dynamic SQL statements and there is a very slim CHANCE that the SQL might exceed 8k, I use a varchar(max) now. I give up efficiency for stability. Another aspect in this case is that I don't have a need to track how close I am to the 8k either.
Now as a develper, my process includes writing the most efficient code I can without profiling every line of code. After that is complete, I will profile the app to get a feel for it's performance.
If it meets the business requirements and I am ahead of schedule, I will look at areas that have the best chance of improvement in performance and see if there is something I can do. I however will often concentrate more on where it can break and improve upon the stability of the app.
Now, if it doesn't meet requirements, I will spend most of my time looking at performance rather than error handling.
If I am behind schedule and I meet requirements... Sorry, I am done.
If I am behind schedule and it doesn't meet requirements, well...it isn't done, but that needs looked at more from a PM perspective.
October 29, 2007 at 1:39 pm
My first programming position was on a DART system - Data Acquisition in Real Time. I got into the habit of squeezing every ounce of speed from the code. Everything was sacrificed for efficiency because that was the breaking point of the system.
It took years for me to get it through my thick noggin that "fasted possible execution" was not always called for and, in some cases, not even the best plan.
There are many characteristics of "good" software: accuracy, efficiency, maintainability and robustness being the four most important I look for. Some environments may require that we place a little more emphasis on one characteristic more than the others but we have to remember there comes a point where we must sacrifice from the other three in order to obtain more from the one.
A good requirements document must address all four characteristics and must rate them in order of importance. If some process can be made 5% faster without sacrificing the other characteristics, go for it. However, if, say, a query can be improved from 15msec average execution time to 13msec but only by making the code extremely fragile (the opposite of robust) then it is generally not worth it.
The same project may even change priorities with time. An application may place maintainability and robustness over accuracy and efficiency at the the beginning of the lifecycle but lower their importance as the application approaches end-of-life. Those are, after all, the development-cycle oriented characteristics and it makes sense to allow them to "age" with the application.
At any rate, where each characteristic is placed in relation to the others is a design consideration which must be specified at the start of development and should be revisited at least at every major release.
In re-reading the above, I foresee replies that will ask along the lines of "what good is maintainability and robustness if you throw accuracy and performance to the wind?" The answer is, of course, that you don't throw anything to the wind. Acceptable levels of each characteristic must be specified and followed. If a process is already within its accuracy tolerance and a change is suggested that would increase the accuracy but make it less maintainable or slower or more fragile, it is generally not a good idea to implement it.
Tomm Carr
--
Version Normal Form -- http://groups.google.com/group/vrdbms
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply