Performance Matters

That’s oversimplifying it. Knuth was writing about micro-optimizations, like writing a section of code in assembly language to shave off some milliseconds from a critical section of code.

What many people today mean by optimization is a far cry from that.

Here’s a real-life example. Some code was super-slow and nobody could figure out why. It took only a minute to see the code was passing a string (in C++) by value, causing unnecessary copy construction and destruction (in a tight loop, to boot).

Writing that code by passing a const reference in the first place is Good Coding 101, but many people might consider that “premature optimization”.

It's the procurment process and the lack of skilled management. With the Ontario eHealth debacle[1], the people in charge were hospital administrators with no software project experience. They were taken advantage of by the contractors, their employees and, to be fair, their own greed. These kinds of large projects really need to spend the money on a real CTO and/or CPO.

[1] https://en.wikipedia.org/wiki/EHealth_Ontario#Consulting_and...

Paper is preferred because it has better performance than the software, which is the thing that people should think about. Writing software that can outperform paper shouldn't be hard to do, but apparently it is.

I don't mean to belittle performance work, but the value of Carmack's successful optimizations in the VR industry doesn't translate to most business.

Let's say we have a $1M/year business opportunity with a requirement that a user be able to take 1MB photos on a phone and have them appear on a PC/laptop which are both connected to a 802.11G access point and on the same internet-connected network segment. The time requirement on this phone->pc transfer will dramatically affect the software development effort in terms of time, money, and skills.

With a requirement spec of 1 photo every 10 seconds, commodity software can already accomplish this. With a cloud account from their smartphone vendor, a user can monitor their photo album from their PC browser, and photos taken on their phone will be sync'd to the cloud, then visible on the laptop. Assuming both devices are on wifi with a typical cable modem connection, the transfer of the photo from phone->cloud->PC-browser would occur within 10 seconds. No software engineering required, supports MAC/Windows/Linux and iOS/Android out of the box.

Now let's spec a 1 second transfer time. Cloud syncing is out; we'll need the phone and the PC to communicate directly over the wifi link; we'll have to write a phone app that sends the photo file over a socket, and a PC app to receive it and display it on screen. 1MB will take 500ms across a healthy 802.11G link, so we have 500ms leftover to allow the phone's camera app to store the photo as a file, for our app to establish a TCP connection, for our PC app to accept the incoming file, and display it in an ImageBox control. We can still meet the 1 second spec on a poor wifi connection... Wait, how does the phone know the address of the PC it's going to send the picture to? We'll need to write our own discovery service to allow the phone to learn the IP of the PC... Should we do layer 2 , or cloud assisted? Or maybe we'll have the phone scan a QR code on the PC in order to link the phone to the PC... We've only imposed a 1-frame-per-second requirement, but we're going to require a software team familiar with PC app development, phone app development, layer 2 and layer 3 network protocols. You could hard code the IP addresses for a quick demo, but you're looking at a small team coding in several languages for several months just to support a single platform (say, Windows PC with Android phone.) Additional platforms will require a repeated effort.

But Carmack would never be happy with 1FPS. What if we spec a 40ms transfer time (24FPS), such that the user could use the laptop/PC screen as a hollywood-movie-grade viewfinder. Now we have to throw away the phone's camera app and write our own that bypasses the save-to-file step and streams the image data directly to the PC over UDP, perhaps RTP. Since the raw camera data takes too long to send over the network, we may also need to visit image compression techniques. Some techniques will be faster on certain phones, so we'll need a heuristic compression algorithm selector to make sure we're correctly optimizing for spending the least amount of time in the combination of compression+transport. On the PC side we'll need an RTP client to receive the data, but also a method to paint the frame buffer data directly into the viewport (no more loading files into an ImageBox control). We may need to explore the gains from painting the image as an OpenGL texture. At this point, our engineering budget has exploded! We're talking about hiring telecom engineers with experience tuning VoIP stacks, digital signal processing and codecs, and video game engine experts to help with low level graphics in OpenGL/DirectX. Perhaps we'd need to retain Carmack himself to advise.

If you have a business opportunity worth $1M/year that relies on moving photos from your iPhone to your Macbook, spec'ing 10s is a great way to get your business started leveraging existing technology. Spec'ing 1s might be acceptable to give your app some polish once you're established, and if you're not FAANG and not Carmack himself, spec'ing 10ms would be a great way to kill your business regardless of size.