In a desktop app, performance only matters when the difference is perceptable to the user. So if something takes a while to open and you could make it faster, then you should make it faster. If, however, it is a question of a few nanoseconds vs. code readability then readability should take precidence. Now when you're talking a different kind of system nanoseconds could become an issue. It all depends on what kind of app you're developing.

The rule of thumb I go by is to create code that is readable first and optimize when necessary. Trying to optimize code for speed as you write it is generally inneffecient at best, and harmful at worst. Often you'll be defeating compiler optimizations, creating difficult to read code, and not addressing the true bottlenecks anyway. The 80/20 rule applies to optimizations- 20% of the code is going to be responsible for 80% of the performance problems. How's the best way to know what that 20% of the code is? To test it and see- not assume before hand you'll know where the problems are going to be.

This is actually an issue at work right now. My boss has ruled that for new projects, all data access needs to be done via stored procs. Now I am well aware that there is a raging debate on the issue of stored procs vs. paramaterized, in-line SQL (and I'd welcome input on this debate from people I resepct here)- I don't really have a "side" on the issue. Like most programming issues, I say make the right decisison for the right circumstance. Even if Stored Procs are the way to go, though, I resent my boss making that decision for us- I think i'dt be better if she'd just trusts us to make the right decisions, although she did say she'd not stop us from writing in-line SQL, but I know if there are ever problems she'll blame it on that without ever looking into the problem for real.

At any rate, her reasons for using Stored Procs over in-line SQL? Speed and maintainiability. "Maintainablility" is a funny argument because while Stored Procs are easy to correct and deploy (since they are in the database), they are much more difficult to organize and read, especially if you do all of your CRUD with them (requiring hundreds of Stored Procs). So I don't know that I buy the whole maitainability thing.

What really gets me is the performance thing though. She uses this argument like a trump suite- how can you argue with performance? However, both in-line sql and stored procs are compiled the first time they are executed and the only performance gain you get from a stored proc has to do with the way it is looked up for subsqent executions (both are cached, but apparently stored procs are cached in a little easier to find place). This time savings is going to be imperceptable to a user pressing a button, but for her it is the knock-out argument. Now I'll totally agree if it is a call that is going to be made thousands of times in a loop where the time can add up, but if it is a simple request in response to a use pressing a button, I think there are far more important concerns than the nanoseconds that might be saved that are impossible for the user to perceive. Things like true matinatability, code readability, good abstraction, etc.

Anyway, I'm tired of people trying using knock-out blows for any coding concept (not anyone here, BTW, just the trend I've seen and participated in in the past). Use the right tool in the right situation. We are not all writing the same apps, therefore we all have different goals at different times. A database application is very different from a 3D graphics engine is very different from a compiler is very different from a . . .