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.

AddThis Feed Button Bookmark and Share

Published Aug 19, 2008
Version 1.0
  • "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?"

     

     

    It seems you missed this statement in your rush to post. I mentioned this in conjunction with the local scope introduction, I did not think it needed to be mentioned *again* for conditionals.

     

     

    Please take a deep breath,re-read, and remember the old saying about "assuming" things - especially about people and their knowledge based on one blog post with which you disagree.

     

     

    Thank you.

     

     

  • @Russ

     

     

    I've worked primarily in the midwest, where control is more important than execution, even in IT. I *have* been forced to change from using the tertiary operator to if-then-else statements, among other strange coding practices that perhaps are peculiar to the land of COBOL, mainframes, and suit-wearing IT folks.

     

     

    The problem is that in one function the impact is negligible, in 20 it starts to build up, in 2000 it's likely noticeable. Latency is negligible when introduced in only one hop, but when there are 20 hops between you and that application, that latency adds up.

     

     

    LOL. Nice parody. It's not so funny however, when you consider that I've been asked many times about profiling tools and how to use them by a fairly significant financial institution in the midwest. They don't do profiling on a regular basis, and they really have no idea how the compiler works. Even after they figured out how to profile using the right tools they still had no idea what to do with the information.

     

     

    While you sound informed and like you understand what's going on, you can't assume everyone is as knowledgeable as you or that every app dev team in every IT dept in every organization has someone like you to help them out. If they did, they wouldn't be asking me for help.

     

  • Don_MacVittie_1's avatar
    Don_MacVittie_1
    Historic 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 ;-)

     

     

    As to coding standards, just don't ask her where the curly-braces go in C++, I've finally gotten past that argument (I was tasked with writing the coding standards at an employer before we were married... I still occasionally hear about that one - 'I' made her move hers).

     

     

    I used to work on low-end cellphones for major manufacturers, and yes, local scoping - creating another layer of stack-based variables - was an issue for us. We reused a lot of variables in scary ways trying to keep the stack size down. Though the ever-decreasing price of memory has probably reduced this problem even in that space, the performance implications were measurable also - we had a guy who did just that, measured differences like that.

     

     

    In the web world though, people should be thinking about this stuff. Particularly the very startups that aren't. Need I point to Twitter? You can save a lot of pain in production by making certain your code performs just as well as it can _before_ two million people are trying to use it.

     

     

    Don.