3 ms·

> the best way to simulate them is simply to run them! And it's quite sad because when you are faced with choosing between two ways to express something in the

> the best way to simulate them is simply to run them! And it's quite sad because when you are faced with choosing between two ways to express something in the code, you can't predict how fast one or another option will run. You need to actually run both, preferrably in an environment close to the prod, and under similar load, to get accurate idea which one is more performant. And the worst thing is, you most likely can't extract any useful general principle out of it, because any small perturbation in the problem will result in a code that is very similar yet has completely different latency/throughput characteristics. The only saving grace is that modern computers are really incredibly fast, so layers upon layers of suboptimal code result in applications that mostly perform okay, with maybe some places where they perform egregiously slow.

mpweiher 2y ago
> you can't predict how fast one or another option will run "The best way to predict the future is to invent it" -- Alan Kay > You need to actually run both Always! If you're not measuring, you're not doing performance optimization. And if you think CPUs are bad: try benchmarking I/O. Operating System (n) -- Mechanism designed specifically to prevent any meaningful performance measurement (every performance engineer ever) If it's measurable and repeatable, it's not meaningful. If it's meaningful, it's not measurable or repeatable. Pretty much. Or put another way: an actual stop watch is a very meaningful performance measurement tool.
- Joker_vD 2y ago
  My point is, it's impossible to test everything in a reasonable timeframe. It would be much, much more convenient to know (call it "having an accurate theory") beforehand which approach will be faster. Imagine having to design electronics the way we design performant programs. Will this opamp survive the load? Who knows, let's build and try these five alternatives of the circuit and see which one of them will not blow. Oh, this one survived but it distorts the input signal horribly ("yeah, this one is fast, but it has multithreading correctness issues and reintroduction of locks makes it again about as slow"), what a shame. Back to the drawing board.

mpweiher 2y ago

> you can't predict how fast one or another option will run "The best way to predict the future is to invent it" -- Alan Kay > You need to actually run both Always! If you're not measuring, you're not doing performance optimization. And if you think CPUs are bad: try benchmarking I/O. Operating System (n) -- Mechanism designed specifically to prevent any meaningful performance measurement (every performance engineer ever) If it's measurable and repeatable, it's not meaningful. If it's meaningful, it's not measurable or repeatable. Pretty much. Or put another way: an actual stop watch is a very meaningful performance measurement tool.

Joker_vD 2y ago
My point is, it's impossible to test everything in a reasonable timeframe. It would be much, much more convenient to know (call it "having an accurate theory") beforehand which approach will be faster. Imagine having to design electronics the way we design performant programs. Will this opamp survive the load? Who knows, let's build and try these five alternatives of the circuit and see which one of them will not blow. Oh, this one survived but it distorts the input signal horribly ("yeah, this one is fast, but it has multithreading correctness issues and reintroduction of locks makes it again about as slow"), what a shame. Back to the drawing board.