4.12 Performance is one of the most important things

Many times today I hear sentences like: “today performance does not matter any longer”. For example when I discuss about java. Normally in the same discussion someone explains me complex techniques use to establish load balancing. That is because performance does matter.

It is annoying, that faster and faster computers do not really give benefits to the end users, because the incredible high performance of the new hardware is almost completely consumed by worse and worse programs.

What I really like for example is, opening and excel version 3 application on a modern computer. It opens in the second the double click is pressed.

Any application should be as fast as possible. There are two reasons for this:

• The user should wait as less as possible on the computer. Instead the computer should wait for the user. The user is a human, the computer a machine.
• It should be possible to reuse any application as a component in other applications. That implies, that an application originally designed to be used via a user interface, could become a component of a batch application that calls the former in a loop many thousand times. Suddenly it would be a mess, if the original application were slow.

4.12.1 Load Balancing

Complex techniques to implement something like load balancing are most of the time the solving of a problem inside the application from outside it. The better way would be to improve the application.

Also it is a bad habit, when application programmers are needed to implement complex performance techniques, just because the chosen programming frame is lame. There are some simple means to guarantee fast programs:

• C: Use the language C. It generates fast code.
• GNU/Linux: use GNU programs and the GNU/Linux operating system.
• Compile time decisions: Any decision, which can be made at compile time, should not be postponed to the run time.

4.12.2 Compile Time Decisions

To get an application as fast as possible, it is important to do any decision, which can be made before run time, at compile time. That is any decision, which can logically taken. So don't argue, that a certain decision is logically able to be taken at compile time, but it is easier to implement it during run time.

This has some consequences:

• Compilers outperforms interpreters. The task of interpreting the code can by done during the build time of an application. So to use bash scripts is generally a bad idea. This is not a reason not to use scripting languages. But in general the scripting language should be able to be compiled into a real binary executable.

  An exception is scripts, which will be written by the end user, to extend your application.

• Machine code outperforms byte code. Many modern languages have the concept of a byte code or something else, which is interpreted at run time. This is halfway from interpreter to compiler. But why not compiling it further on to machine code? What is often answered: because it should be portable. But as gcc shows, a compiler can be as portable.

  An exception to this is the situation, like in web browsers, when you provide applications at click time to machines you don't know. Then a byte code is the solution. That means: java is good for web browser applets, but not for server applications.

• Real machine outperformce virtual machine. This is more or less the same reasoning as for the machine code. The byte code interpreter can also be called a virtual cpu.
• Static outperforms dynamic html. So, if you want to reuse components designed for use to generate dynamic html pages, in the creation of static pages (which generally is a good idea), then you should incorporate these components in the building process of your application. The the html building components are active during compile time, to create the static html and during run time to create the actual dynamic pages.

4.12.3 Creating new Processes

A special note I want to give on process creation. On GNU/Linux machines the creation of new processes is relatively fast. And in bash programs there are a lot of processes created. I call them programs, because they are programs. Often they are called scripts, because these programs are interpreted, and because there is an easy interface to the underlying operating system.

In bash programs processes are created for each command, which is not an internal command. That is for each line, which is a command, for each backquote and for each pipe. These mechanisms make it easy to write bash. It allows to reuse existing executables to write new functionality. But there is often no special reason to create processes. It is just because bash is designed so.

If you take perl as another scripting language, there is a lot of work done, not to create processes time and again. Many unix commands and all C-functions are available as internal functions. This is the better way.

Siliconbrain creates a process creating executable for each siliconBrain command. This is to make it possible to test those commands from within for example bash-scripts. And it gives a user the possibility to use those commands by just typing them into her command line. Also gives the flexibility to write shell script programs using siliconBrain commands, but this is not recommended. Instead use C and the siliconBrain environment to create new applications, which are in itself commands.