> Both 1 and 2 are solved by profiling.

This is a very simplistic view of how software measurement works that is pretty pervasive in academia, but doesn't actually translate all that well. If you're sticking to only typical profiling methods (which tells you very little about things like latency and doesn't tell you at all about many sources of slowness), you still need to find a way to do it in a low-impact way if you actually want to measure a software system of any complexity. As an example of another technique, tracing (and even just reading logs) can give you a lot of interesting signal that profilers don't generally capture.

Most commercial software systems have a number of lines of code (and a code profile, by the way) comparable to the Linux kernel, so if you're just going to apply a simple profiling methodology to it, you're going to get a lot of crap data and you're going to slow things down a lot. Performance engineering is about extracting signal from the crap.

> The course involves assembly because it’s taught in C, but the core concepts apply to any language

I never said I wrote assembly, I said assembly-level code, which you can write in most languages. You can write it in Python if you are skilled enough at Python. Many people do it in Java and Go. I usually do it in C. Most of this kind of code these days is not actually written in assembly.

> Your trading system example sounds like a great topic for a masters thesis or similar graduate level work (or better yet - industry), not a core component of an introductory performance engineering class.

The primary point I am trying to make is that a class called "micro-optimization" should be teaching you how to micro-optimize code. A class called "performance engineering" should nominally be teaching you about how to actually do performance engineering, which is actually not all that related to micro-optimization.

I’ve used techniques I both learned and taught in that class to dramatically speed up many real world large scale systems. Yes, not every aspect taught is applicable to every system (one thing we mentioned many times is that many of the micro-optimizations we explained were done by a modern compiler anyways, which is why we even brought up assembly). But those techniques are still useful historic context for the subject, which is exactly what you’d except an introduction class to include for the first lecture, along with a live demo that gets people excited about the class and willing to keep going with it.

The class is not about micro-optimization. The first couple lectures are. But people in this thread love to read their titles and stop there. I don’t get it. Here are the lecture notes for measurement and timing, you’ll notice they include what you say about separating signal from noise. I’m sure you, with tons of industry experience behind you, know more than this introductory undergraduate’s lecture in the topic provides (it’d be quite sad if you didn’t!), but that does not mean the class does not indeed provide an introduction to the topics. One that, again, I have personally built upon to dramatically speed up countless medium-to-large scale systems in a wide variety of contexts. https://ocw.mit.edu/courses/6-172-performance-engineering-of...