On Performance

September 18, 2019

Performance of your workstation is important and I’ll tell you why.

I remember seeing one particular macro image on Instagram which greatly irked me then.

On the top side of the picture there was a photo of the huge three-screen workstation setup with gaming chair, enormous table space, huge tower of the PC itself and a lot of LED backlights which newfags love so much. This half of the picture had a caption “computer on which the games are being played” or something like that.

On the bottom side of the picture there was just a photo of some dirty, scratched laptop with the design straight from ’00s, implying it’s at least that old. This half of the picture had caption “computer on which the games are being developed” or something like that.

To say I was confused by this picture is to say nothing, because it should actually be reversed.

Person who made that image, and it’s probably a lot of them, because I saw similar images on Instagram several times, not just once, so, those people just don’t have a clue how games are actually made.

I personally heard a single confession from one particular solo indie developer that he indeed uses quite an old laptop to develop his game, and he does that exclusively because if he is able to develop and test the game on such a low-spec machine, then his players for sure will be able to run the released game on a similar low-spec machine.

I can’t imagine developing any significant portion of a game like Witcher III on a laptop. Any laptop, including $4k HP Spectre one and such.

This made me think about the importance of raw hardware performance in a life of the software developer in general. Because, you know, I’m not a game developer, I’m a Web developer.

Everything boils down to the length of the feedback loop, really. I don’t know about you, but for me, the most complicated and time-consuming part of my work is not actually writing the code. It’s not even design.

It’s testing, actually launching the software under development. This is what is the most time-consuming part of my day to day job.

Not even talking about launching all the tools required for development, like Web browser (for documentation and live preview), IDE itself, myriads of plugins for the IDE, Slack, file manager.

Gary Bernhardt, which certainly knows more about software engineering than me, talks extremely honestly: if the flow of programming is broken for more than 300ms he’s probably already became distracted.

This is the fundamental issue. It’s possible that I’m the most impatient programmer on earth; I want my feedback to be so fast that I can’t think before it shows up. If I can think, then I’ll sometimes lose attention, and I don’t want to lose attention.

I aim for test feedback in 300 ms, from the time I press enter to the time I have a result.

— TDD, Straw Men, and Rhetoric, posted on 2014-04-30

Seriously, go read that “TDD, Straw Men, and Rhetoric” article.

Now, ask yourself, can you achieve 300ms long feedback loop? Can you achieve even 3s long feedback loop? He can, but that’s not my point, and he’s doing that from the other way around: he’s simplifying the tools, which is also not my point.

My point is that a competent software engineer must thrive for faster feedback, and it should be a thing as natural as breathing.

I did an upgrade of my workstation recently. I finally was able to migrate from the laptop I had to use for over a year to the proper desktop machine. Here is realtime recording of the yarn installing 994 packages from scratch to my current work project:

It takes 8 and a third seconds to do that. Note that the GIF includes additional couple of seconds to remove the existing contents of the node_modules folder before installing them again.

I can clean the yarn cache and perform a 100% cold install, and it’ll still take just 20 seconds:

Powerful machine is not a toy to boast with. I made a rig with i7-9700, 32GB of RAM, M.2 drive and I even dropped a latest Nvidia RTX-class video card to relieve the CPU from the unnecessary burden of graphics processing. But I did that not to overwhelm you with how much money I am able to spend or what numbers I wanted to cram into this article.

I did that to simplify my life, and I urge you to consider doing that for youself as well.

Want to know how much time it took on the laptop I was using before upgrade to do the same rm -rf node_modules && yarn trick above? 510 seconds just for yarn! GIF file with recording have too large size to be included in this page. If you clean and reinstall the npm packages often, you can enjoy the boredom together with me in the separate tab.

To be honest, I cheated a bit with the yarn example. Its performance is severely bound by the disk drive, which is quite easily replaced.

Better comparison of the raw power would be the full TypeScript build of the same project, almost entirely in-CPU procedure. On the new machine with i7-9700 and 32 GB RAM it takes 7.66 seconds. On the old laptop with i7-6500U and 8 GB RAM it takes 48. It is the 526% increase in performance, and again, how often you build your project in a typical work day?

CPU performance directly translates into seconds saved waiting for compilation.

Huge amounts of RAM free your mind from the thoughts of what application to close just so Google Chrome will not bring your machine to knees by swapping yet again. You just stop closing the applications altogether, because they all fit in memory at once.

Fast system drive does wonders to dynamically-processed languages like Javascript, and make all the applications in your system to launch faster, including all the environment, toolchains, everything. Seriously, invest in SSD as soon as possible.

How much time your application take to build and launch so you can test your changes live? One minute, five, ten? How many times do you have to launch it in a typical work day?

If you are forced to wait for two and a half minutes every build, what do you do in that time? This is enough to brush your teeth clean. To watch a music clip on Youtube. Read a page or two or four of a book. Scroll several screenfuls of Twitter on your smartphone. Such a huge time delay will stop your state of the flow and potentially will erase the context from your mind completely.

Performance directly translates into your own productivity, so if you think about where exactly to invest in yourself, I would suggest investing into your hardware. Do not neglect it.

I half expected the difference when I did the upgrade, but I still was really impressed, enough to write this long rant for you. I hope the examples I provided support my point perfectly well.