[hedora]

I wonder how much adding a profiler to development flows would help modern apps.

JS is gross, but 16ms (time you get to render a frame at 60 fps) is an eternity on modern systems.

It’s tens of millions of single-threaded CPU cycles.

Also, you probably can use GPU acceleration for client code. That’s enough time for a 2026 integrated CPU to do tens to hundreds of billions of tensor ops.

And yet, the iOS keyboard (presumably multithreaded and native) cannot reliably echo keystrokes in under a second. I regularly see webpages take multiple seconds to redraw a screen.

[Sohcahtoa82]

I often think about DOOM running on a 66 Mhz 486.

It ran at around 30 fps with a 320x200 screen. That's 64,000 pixels per frame, 1,920,000 pixels per second being rendered.

On a 66 Mhz CPU, that means less than 35 clock cycles per pixel, on a CPU architecture where a multiply or add instruction would take multiple clock cycles to complete.

I know DOOM was not a true 3D engine and it took a lot of shortcuts to look the way it did, but that makes it more amazing, not less. The amount of thought to go into it is just mind-boggling to me.

[cogman10]

> multiply or add instruction would take multiple clock cycles.

Add, and, or, xor, and bit shift have always been single cycle operations for integers. Doom used integer math for everything I believe.

[Sohcahtoa82]

Ah, so you're right.

Still though...care had to be taken to make sure memory was organized to maximize cache hits.

I feel like the crazy optimizations necessary in those days have become a lost art to most game developers.

[Archit3ch]

> I wonder how much adding a profiler to development flows would help modern apps.

Very much, but ideally you want telemetry on the user's device (assuming desktop app). Or your "optimization" might come back as a regression on the Snapdragons you didn't test on.