Another Micro-Optimization Provides Useless Results

One of the things to remember about performance optimizations performed in isolation is that their results are rarely representative of real-world performance results. This article outlines the “findings” of the students at a couple of Canadian universities, and comes to the conclusion that string concatenation in memory is slower than writing the same total number of bytes to disk, one after the other.

String concatenation is a slow and CPU-heavy operation. It drastically affects Micro-Optimization testing when both algorithms do not utilize it.

If you don’t immediately see the issue with the algorithm in which the study is utilizing, it will become apparent shortly. You see, when writing to disk, the students were simply writing X bytes at a time to a location on the disk, moving over, writing more. However, when doing it all in memory, they were implementing string concatenatation. These two operations require vastly different amounts of CPU cycles to complete, adding a variable to the performance equation that was not considered in the evaluation.

If the students were actually comparing disk performance versus memory performance, they should have first created a ramdisk and ran the same code against the ramdisk and the normal filesystem on a hard drive or ssd. By creating the ramdisk, you are able to write to a reserved section of memory using the same codepaths in Java and Python that are used for writing to disk, the only difference being the destination and the drivers for that destination, which is as close as possible to comparing two different storage media.

Related Posts

Apr 29, 2014
2 minutes

Avoid jQuery.bind()

When chasing down performance issues, you never know what kind of problems you will find. I was looking for something that would cause jitter when scrolling on the page. After looking at the custom code that runs on every scroll event, I still had not found a reason for the jitter. Looking at the JavaScript CPU profile when scrolling in Chrome showed that there was an overwhelming majority of the time spent in a function in the Prototype JS library.

Mar 17, 2015
2 minutes

When Is Enough CSS Enough?

One of the major pushes in web development today is to try to do as much of the styling of a website as is possible from within the CSS of the site. The idea behind this is that when you do so, you remove styling responsibilities from your JavaScript and HTML content, resulting in a much better separation of concerns. The other aspect of this is that CSS styling is typically handled in a more native fashion in the browser as compared to what you can accomplish via Javascript.

Mar 23, 2015
2 minutes

Google Chrome Improves JavaScript Speeds Again

One of the old rules of optimizing website load times for all browsers was that the browser didn’t begin to parse the downloaded JavaScript until each file was downloaded. Starting with Chrome 41, Google has announced that this is no longer the case.

In this announcement, Google has said that new versions of Chrome will begin parsing JavaScript as it is downloaded to the browser, even before the particular file’s download is complete. However, in order to see this happen more quickly, you must utilize the async or deferred tags in the <script> tag. JavaScript that is loaded without async or deferred is still a completely blocking action that pauses all rendering while downloading and parsing the JavaScript files. According to Google, this can improve website load time by up to 10%.