All your performance are belong to us

The evolution of programming languages and environments and the impact on performance

Chances are that if I ask my son, a third-year computer science major, about Big(O) I'll either get that look - the one that says he's had that discussion with his father years ago and he really doesn't want to discuss such things with his mother - or he'll dismiss it as not relevant to today's computing environment. Big(O) and algorithmic performance is just not that important to today's generation of developers who are too often being taught to code within a vaccuum, or to be more accurate, inside a virtual machine that takes care of most of the dirty work for them.

The most popular of developer environments and languages today, those being taught to would-be developers in college and used extensively in the enterprise, are primarily interpreted, virtual-machine executed languages. Java. C#. VB.NET. These languages take the "guesswork" out of dealing with low-level, dirty concepts like memory allocation and deallocation and automatically optimize common syntactical constructs.

But that means that developers can no longer choose between malloc() and calloc(). And indeed they likely do not understand the performance implications of choosing one over the other. They cannot decide when garbage collection occurs, a process that has long plagued Java as one of the primary causes of temporary performance problems in high-volume server-side applications. They turn to using pre-built data structures such as Vectors or Collections, and haven't the foggiest clue how to create, manipulate, and manage a true array on their own. The layer of veneer placed over these "low-level" functions removes complexity and thus improves the quality of the code, but does so at a price - performance.

In short, today's developers are limited in their ability to optimize code by their education, experience, and development environment. They can make performance worse, but there is an upper bound to how well they can make an application perform, and that upper bound is controlled entirely by their environment.  

This means enterprises are dependent upon the ability of the pre-compiler and interpreters (virtual machines) to optimize the code and the run-time environments. But because the ISVs providing those tools and environments must account for hundreds of scenarios, the tools are rarely as optimized as they could be. They are "good enough" for general use and rely upon the steady increase of resources and performance on the computing platforms upon which these tools and applications will be deployed to keep performance at an acceptable level.  

It's not always enough.

Traditionally it has been the case that once an application is deployed and performance problems crop up that the finger pointing begins. Developers point to the network or the platform as the cause, conversely the network team points at the developers.

Both are likely wrong in assuming the fault lies with the other. In many cases there simply aren't any more tweaks possible within the code and the network is performing exactly as it should. The fault often lies in the one place that neither the network or application teams can affect: the operating system and the application platform. It's a matter of protocol efficiency, from layer 4 (TCP) up through layer 7 (HTTP). These inefficiences are inherent in the operating system and network stacks and they are not something an enterprise can affect directly. 

They can, however, address these inefficiences with application acceleration solutions. App acceleration products address the problems inherent in HTTP like chattiness and TCP in a variety of ways, including implementing the rather lengthy list of RFCs designed specifically to improve TCP performance and behavior. Products like F5's WebAccelerator add file and object level caching and compression on top of protocol-specific enhancements to overcome the limitations of operating system network stacks and application platform environments. In many cases these solutions can further optimize specific applications like those from Oracle, Microsoft, Siebel, and SAP by addressing inefficiencies in their protocols, improving performance even further.

Application acceleration solutions improve performance of applications by addressing the issues that cannot be readily addressed by developers or application and network administrators. Developers can, of course, go back to using more easily optimized code such as C/C++ or even assembly, but that's not likely for a number of reasons including increased complexity, increase time for development, and the reality that there are a dwindling number of developers who are skilled in these languages.

You can tweak the network all you want, and send developers back to stare at code that can't be optimized any further, but in the end neither option will likely improve the performance of the application. The most cost-effective, optimal solution is to implement an application acceleration solution for those applications for which performance is critical.

Imbibing: Pink Lemonade