When Speed of Light is Not Enough

Fast, fat computers breed slow, lazy programmers
-- Robert Hummel --

As it is stated in our "Mission Statement", our aim is to write fast software, which uses as little resources as possible. On this way we have found that it is not enough to optimize software later (for example, as proposed by "Extreme Programming" principles), but it is necessary to build application from ground up with performance in mind. It is a very challenging task because it is very easy to spend lots of time optimizing things which are not necessary to optimize, or even worse not to complete any code at all because of eternal optimization, but we hope that we found right approach to address this challenge. Our policies in regard of performance are the following:

• While optimizing code is not a primary goal when it is originally written, avoiding inherently inoptimal algorithms shall be done at the very early stages

  It means that while we do not want to go into low-level (for example, assembler) optimization when designing algorithms and writing software, outright inoptimal solutions shall be avoided from the very beginning. For example, while optimizing sort is not a task we will do at early stages, making this sort O(N*log(N)) rather than O(N*N) is an absolute must; the same goes for avoiding O(N) operations when they can be avoided.

• "Optimize for free" policy

  There are several very common cases when more optimal code goes for free in terms of developer effort and code readability. In such cases the policy is to write optimal code from the very beginning. One such very prominent example is to move function calls out of the loop as much as possible.

• "Make job of compiler easier" policy

  While modern compilers are generally smart, there are very many of them, and every one has it's own likes, dislikes and idiosyncrasies. Still, there are many techniques, which help compilers in general while improving overall code quality; in such cases developers are strongly encouraged to use them. One of the very prominent examples of such technique is C++ 'const' keyword.

• Performance-optimized libraries and APIs

  We have our own set of libraries, which are performance-optimized. Moreover, our library APIs are designed in the way which makes it difficult to use them in suboptimal way.

• Dedicated optimization developer

  Our model assumes that a dedicated optimization developer shall start working on the module code as soon as stable version of the algorithm is released. The aim is to compile the code for some very specific platform, and then analyze bottlenecks, take a look at assembler code, and suggest generic algorithm and/or specific CPU-dependent optimizations. It is an ongoing process, which helps both with improving reliability (because it greatly improves number of ways the module is used), and obviously to identify and eliminate bottlenecks at earlier stages, when it is not that expensive to deal with them.

• Performance testing in close to real life environments

  Unlike most developers, we are performing performance testing from the very early stages, and are monitoring performance during subsequent changes. In addition, we are performing testing in close to real life environments; it means that if the product we are developing is a server product, we will test it's performance from the very beginning on somewhat typical server, rather than on developer's desktop (or even worse laptop).

• Built-in tools for customer-end performance analysis

  All our software has extensive statistics gathering framework built into it, plus special versions can be easily produced if necessary to gather even more statistics about internal processes.