How Coding Standards Can Impair Application Performance
One of the "real world" lessons rarely taught in the university setting is that in the "real world" you're going to have to follow coding standards. Back in the day, when I was allowed to code, I often railed against some of those coding standards on the basis that they impaired application performance.
Anyone with a firm grounding in computer science knows that the introduction of a local scope necessarily means more work (and thus memory and cycles consumed) to set up the stack: copying variables, pushing parameters, etc... That means that a conditional statement with just one statement unnecessarily introducing a local scope degrades performance. But that price is often willingly (or unwittingly) paid in the enterprise because of coding standards which dictate format of code. Sure, modern compilers often optimize that code anyway but are you sure yours does? Have you checked? Does it require a flag and has that been set for all applications?
The same problems exist with certain language constructs, such as if-then-else versus switch versus the "{condition} ? {true statement} : {false statement}" construct. Enterprise coding standards meant to ensure readability and thus maintainability of the code require one over the other, regardless of which construct may be the most efficient in terms of execution (hint: it's the "? :" form).
And I won't even go into the inefficiencies introduced by layering abstraction upon abstraction over standard data structures. But it's likely that somewhere in the enterprise there is a document that says "you will use a Vector and not a primitive array" because it's easier, better documented, and less likely to introduce an array of potential vulnerabilities into the application. My apologies for the pun. Seriously, I feel bad for that one.
Needless to say, I lost my arguments and it's likely that most folks today would as well.
So what's an architect or developer to do when poor application performance has users and management screaming at them?
There's not a lot you can do. At some point it becomes impossible to optimize your application further without destroying manageability and readability. The long term benefits of coding standards for web applications generally outweigh the gains in performance. So you have to start looking elsewhere for ways to make that application faster - like the underlying protocol stack and network connectivity.
But developers don't generally have control over those aspects of an application, either. Unfortunately, neither do web administrators or network architects. That's when it becomes necessary to look at external solutions, and that's where application acceleration and optimization can help.
Technologies like application acceleration and optimization can't address the inefficiencies in code introduced by data structure choices or coding standards-imposed use of specific constructs, but they can help offset the degradations introduced by those coding standards by improving the performance of network and application protocols and employing a variety of data reduction techniques.
By taking advantage of application acceleration technologies, you can improve the performance of your application without having to sacrifice coding standards or, if you're willing to do so, rewrite the application. Application acceleration and optimization solutions can improve the performance of applications by modifying the behavior of underlying transport and network protocols, reducing the amount of data being exchanged, and optimizing network connections. These technologies improve application performance transparently, without the need to re-architect applications or its network infrastructure.
- Lori_MacVittieEmployee"Sure, modern compilers often optimize that code anyway but are you sure yours does? Have you checked? Does it require a flag and has that been set for all applications?"
- Lori_MacVittieEmployee@Russ
- Don_MacVittie_1Historic F5 Account@Russ, "use fear to drum up business" is not Lori's style, nor indeed is it F5's, though the voice-over is funny ;-)