Software Optimization: A Systematic Approach | Hacker News Reader

Software Optimization: A Systematic Approach

jeffknupp.com

12 pointsjknupp4 comments

Why I appreciate articles about Software Optimization and I also think that it is often underrated I have experienced in last projects something slightly different: The systems on which I worked were composed by several separate processes that are spawned in chains and communicate mostly over files. While this might seem an arcane architecture by today's standards it has the advantage of high flexibility, because you can replace/optimize every single process at the OS level and you can very efficiently introduce new logic and even make the system scale over many machines.

However in this case case the bottleneck is IO and not CPU. And hence the optimization in this case would be to minimize file access, rereading information that was already present at prior steps of the process chains. I would love to learn efficient methods to measure in such architectures what are the spots to optimize.

An upcoming part of the series discusses determining what work is necessary, at a very fine level, and working to remove all else. This may seem like a needlesly simplistic exercise, but consider the example you gave: the processes need to communicate with one another. The method by which they do so is an implementation detail. Even if they eventually use the files for another purpose, those are two separate requirements (the first to communicate with other processes and the second to journal that communication). Replacing file based communication with something like a simple TCP based message protocol would likely yield great dividends. For processes on the same machine, an IPC mechanism like domain sockets or shared memory would surely be faster.

Of course, the first thing to do is determine if increased performance is actually required. No sense in making something fast if no one benefits.

For processes on the same machine, an IPC mechanism like domain sockets or shared memory would surely be faster.

Why are you sure that these would be faster than reading and writing a file?

There is a key truth to be mindful of while doing optimization work: programmers are, as a rule, terrible at anticipating at the cause of slowness in their application. This is counterintuitive but almost always true.

+1 to communicating through files.

Another advantage to this, which people mostly overlook, is the fact that you have a dump of intermediate data at no (additional) cost -- which makes it very helpful when you debug, and more than pays for itself when you want to redo some parts of the processing chain -- request/reply based processing (e.g. pulling from a database) that doesn't post intermediate results, would have to start from the beginning.

Furthermore, if you have enough ram, Linux is extremely good about managing the buffer caches (both read and writeback), so in the common case you get memory performance and disk durability.

It looks arcane, but communicating through files is a good, unappreciated way to communicate.

Reply on news.ycombinator.com