Hacker News Reader

Comment by gwern | Hacker News Reader

> The MPV patch of v0.1 is without a doubt build 36 (e16bab8). The "Cripy optimization" turns status bar percentage rendering into a noop if they have not changed. This prevents rendering to a scrap buffer and blitting to the screen for a total of 2 fps boost. At first I could not believe it. I assume my toolchain had a bug. But cherry-picking this patch on PCDOOMv2 confirmed the tremendous speed gain.

Good example of how the bottlenecks are often not where you think they are, and why you have to profile & measure (which I assume Viti95 did in order to find that speedup so early on). The status bar percentage?! Maybe there's something about the Doom arch which makes that relatively obvious to experts, but I certainly would've never guessed that was a bottleneck a priori.

View on HN

Example: "Our app was mysteriously using 60% CPU and 25% GPU. It turned out this was due to a tiny CSS animation [of an equaliser icon]"

https://www.granola.ai/blog/dont-animate-height

Why was the solution to optimize the animation instead of... using a static asset?

We paid for the whole CSS spec and we're gonna use the whole CSS spec.

This, but for everything wevdev-related in the past ten years.

Because it provides an indication that the app is receiving your voice input?

I think they're suggesting an animated PNG or GIF.

Or even better an animated SVG. Put it inside an <img> tag with a known width and height.

I'd be very surprised if SVG animations don't use substantially the same rendering paths that CSS animations do. In fact, if anything, I'd expect CSS animations to receive more time and attention from browser devs than the old SMIL elements and attributes, to whatever extent that they aren't equivalent internally.

SVGs are usually animated with CSS.

Yeah but the crux of the problem is when height is animated the browser needs to redo the layout. Here the animation is contained entirely within an <img> tag with known width and height.

That's something I'd use a canvas or even a SVG for. SVG FFT Analyzer sound like a fun project.

Oh, looks like I'm way late: https://cprimozic.net/blog/building-a-signal-analyzer-with-m...

How would an animated PNG or GIF respond when the user is speaking?

Switch between different PNGs depending on voice activity.

that's how veadotube works for vtubers.

I assume there's a way to pause a gif.

That would be more optimized for sure. But it wouldn't be scalable and would take more work to create than what looks like a pretty simple change.

I remember Slack eating up my CPU when it had to display several animanted emojis at once. Use some 20+ emojis and the intel mb pro couldn't handle it. Luckily they knew and there was an option to disable the animation. Now I have no idea if they fixed it since or it is one of those things that was "fixed" by M1.

Would like to see a write up on how it's even possible to achieve that when PCs from 20-30 years ago had no issue with such task.

> Would like to see a write up on how it's even possible to achieve that when PCs from 20-30 years ago had no issue with such task.

Electron.

But that's just a browser, right? I'm pretty sure my browser in 2005 could display dozens of gifs. There must have been a series of decisions by devs to do it in some super convoluted way. I can see each emoji being an iframe with a full react app doing the animation. But even that should be fine? Maybe?

It's "just a browser" in the same sense that the Linux kernel and GNU are "just an operating system".

It's one of the most complex pieces of software - perhaps even human designed systems - ever to exist and we're using it to render a few polygons and drop shadows because the C++ committee made a bunch of mistakes decades ago so now our webdevs are mortally afraid of CMake and Qt/QML. Or GTK. Or whatever. Pretty much the only people that seem to put out native GUI tools in any significant quantity are Apple developers.

The tradeoffs that Blink and V8 engineers have made to support the entirety of the internet and the morass of web development precludes efficient use of resources for simpler purposes, like rendering an animation. After all, there a billion React hooks and ad tracking scripts to optimize, otherwise bounce rates will increase.

> precludes efficient use of resources for simpler purposes

Strong disagree. If it were an animated gif then the browser will be astonishingly efficient because of crazy good optimisations.

The underlying reason is that developers are limited to the techniques/toolbox they know. The performance costs are unpredictable because of:

(1) the declarative style (using imperative solutions would have other costs),

(2) debugging browser performance regressions is difficult (SQL EXPLAIN is more learnable).

Browsers enable developers. I could design that animation in CSS even though I'm a developer, plus I understand the article fully. I couldn't design an animated gif because I am totally unfamiliar with any tools for achieving that.

I think the Blink and V8 teams do an exceptionally good job when choosing compromises. HTML/CSS/SVG/JS and Chromium are winning the UI wars because they deliver practical and efficient enough solutions. Other UI solutions I have experienced all have other downsides. Browsers are magical.

I mostly really agree with your comment.

Animated gifs are probably not an issue anymore. In the case of the equalizer icon, the OP used CSS animations that made the browser work in a very non-optimal way. Same thing probably applies to the animated emojis.

Part of the problem is that because it's "just a browser", devs have to come up with browser-friendly ways to implement some functionality that would be very simple if it were a native app. Sometimes resulting in bugs like https://github.com/microsoft/vscode/issues/22900 ("VS Code uses 13% CPU when focused and idle, draining battery ... due to the blinking cursor rendering").

Note that this isn't even a case of whoever implemented that cursor "doing it wrong"; to quote another comment on that bug from a Chrome dev:

> Powerful* text editors built on the web stack cannot rely on the OS text caret and have to provide their own. In this case, VSCode is probably using the most reasonable approach to blinking a cursor: a step timing-function with a CSS keyframe animation. This tells the browser to only change the opacity every 500ms. Meanwhile, Chrome hasn't yet optimised this completely yet, hence http://crbug.com/361587. So currently, Chrome is doing the full rendering lifecycle (style, paint, layers) every 16ms when it should be only doing that work at a 500ms interval. I'm confident that the engineers working on Chrome's style components can sort this out, but it'll take a little bit of work.

While that's part of it, it's also that there's simply little focus on performance; developers trust the system they build on top of, and animations are a solved problem in terms of performance, right?

Animations on a HTML controled by a css are a solved problem.

It is a bad idea.

> I remember Slack eating up my CPU when it had to display several animanted emojis at once.

I remember using phpBB back in the late 2000's, viewing a page that had at least 100 animated emoticons on it.

It would slow IE6 down to a halt. But then I tried Chrome or Firefox (I forget which one) and it didn't even blink showing the same page. I even remember reading some developer posts about things like that at the time.

> Would like to see a write up on how it's even possible to achieve that when PCs from 20-30 years ago had no issue with such task.

At a guess, by something in the UI framework turning an O(n) task into an O(n^2) task. Seen that happen in person, the iPhone app was taking 20 minutes(!) to start up in some conditions, the developer responsible insisted the code couldn't possibly be improved, the next day I'd found the un-necessary O(n^2) op and reduced that to a few hundred milliseconds.

The over-abstraction of current programming is, I think, a mistake — I can see why the approach in React and SwiftUI is tempting, why people want to write code that way, but I think it puts too much into magic black-boxes. If you change your thinking just a bit, the older ways of writing UI are not that difficult, and much more performant.

I have a bunch of other related opinions about e.g. why VIPER is slightly worse than an entire pantheon of god classes combined with a thousand lines inside an if-block: https://benwheatley.github.io/blog/2024/04/07-21.31.19.html

Or more recently, NPM's infamous "Progress bar noticeably slows down npm install #11283" issue

[1]: https://github.com/npm/npm/issues/11283

A thing I discovered by myself when I was a teenager: do not update progress bars on every loop.

There's a lot of things front-end developers (be they web or graphical terminal) can learn from the game development world. I can recommend playing with e.g. Pico 8 sometime, it's artificially constrained so you have to work with the limitations instead of do the usual relatively naive work. It's LUA coding so it shouldn't be a problem for JS developers, assuming they don't mind working in a 20 column code editor (or thereabouts).

Games developers are not magically safe from the progress bar mistake.

I think it’s more so important to get familiar with loop/event based programming. Most of my experience is in the request/response mindset of web requests so when I try out game dev, arduino dev, C# desktop apps, etc I find my mental model has to shift drastically

Loops occur so fast it’s pretty standard to have to put some throttling logic in the code which I’ve never had to do in web dev except perhaps the document.ready statement in JavaScript to make sure the dom has been loaded.

Same here. I often implemented like this, where n was some reasonable value:

    if iteration % n === 0:
        update_progress()

I normally do it with a bitwise and of numbers that end with a sequence of 1s, like 7. so `i & 7 == 7`

This is why it pays out to turn on "Paint Flashing" [1] in the web console, even if just from time to time.

1: https://web.dev/articles/simplify-paint-complexity-and-reduc...

Me, who already renders a canvas on the whole page so it highlights the whole thing constantly: "Hmm yes the painting here is made out of painting."

That's cool, I don't know how popular canvas heavy apps are these days, what kind of apps are you working with?

I used to work on a set top box app, and for some of the features, replacing the whole page with a single canvas was the only way to get steady FPS.

This reminds me of having to go into spotify's package files to track down their version of this animation (an animated svg of a bar chart) and kill it, because it would destroy performance on my PC so badly that it was affecting other programs, causing hitches and freezes.

The animation's still there — and my PC is better now, so it doesn't stutter — but I'm willing to bet it's still burning waaay too many watts, for something so trivial.

CSS animations make Flash look efficient by comparison.

Reminds me of the performance optimization somebody discovered in Super Mario World for SNES, where displaying the player score in was very inefficient, taking about 1/6 of the frametime allocated.

"SMW is incredibly inefficient when it displays the player score in the status bar. In the worst case (playing as Luigi, both players with max score), it can take about a full 1/6 of the entire frame to do so, lowering the threshold for slowdown. Normally, the actual amount of processing time is roughly proportional to the sum of the digits in Mario's score when playing as Mario, and the to the sum of the digits in both players' scores when playing as Luigi. This patch optimizes the way the score is stored and displayed to make it roughly constant, slightly faster than even in the best case without."

https://www.smwcentral.net/?p=section&a=details&id=35746

As a gamedev, those slowdowns are common. Ui rendering, due to transparency, layering and having to redraw things, and especially from triggering allocations, can be a real killer. Comparing old vs new before allowing it to redraw is really helpful. I found layers and transparency was a killer in css as well in one project, but that was more about reducing layers there

Drawing to the screen is a IO operation, is going to be slow.

My favorite example of this is the GTA Online insane loading time issue that ended up being due to poor handling of a 10MB json file (and was finally tracked down by someone outside their org). Took a 6 minute load time down to just under 2 minutes:

https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...

Reminds me of the incident where npm was 2X slower than it should have been because of the fancy terminal progress bar:

https://news.ycombinator.com/item?id=10974929

I had a similar case when I work on a Matrix client (NeoChat) and I and the other devs were wondering why loading an account was so slow. Removing the loading spinner made it so much faster, because the animation to render the loading spinner uses 100% cpu.

A common one for server apps is logging, especially to the console.

It’s far more expensive than people assume and in many cases is single-threaded. This can make logging the scalability bottleneck!

Logging to a 'serial' console can stall the whole kernel, wrecking latency, and this can easily show up in VMs since a lot of them emulate a lowest-common-denominator UART inerface as the kernel console.

I remember setting a server’s console baudrate in EFI to its higher setting improved boot times, hehe.

The original Doom must have been heavily profiled by id though, surely? Obviously there is a bunch of things that were missed, but I was in game dev at Doom time and profiling was half the job back then.

What tools did you have in 1993? From what I understood, id Software used NeXT because the tooling was not up to the task.

Yikes. Now you're pushing my memory. I believe there was a profiler built into Visual Studio and we had some external tool, too. We had some sort of system set up with serial cable to debug and profile. The EXE would download onto our test PC next to us.

Problem for id is that you have no sane way of profiling the DOS port on NeXT.

Visual Studio? The first released Visual Studio (Boston) was released in 1997. Doom was developed during 1993 :P !

He may well be thinking of Microsoft Visual C++, which dates back to 1993 and evolved into Visual Studio. It had a profiler.

https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B

Doom was developed on NeXT machines, not Windows.

Although the DOS version was compiled using Watcom C, so presumably they'd use Watcom's debugger for testing the DOS version.

This. Thank you. I thought it was Visual Studio. It's been a while...! The games were a wretched mixture of C++, C and x86.

I use VC++ in 96. Just trying to learn a bit of C++!

Well yes - it was an incredible feat of performance engineering. It's just that since then someone managed to make an extra three thousand commits worth of micro optimizations.

True. And Carmack and team only had so many hours in the day.

And it us easier in a non moving target.

Until razer comes in and lands a patch authored by an intern that tanks framerates to 1/3rd doing glowy USB shit every frame...

https://www.reddit.com/r/Doom/comments/8a1m9s/psa_deactivate...

There is no evidence of any profiling in source code. It wasnt a thing you did in 1993. The best you could do was compile whole game with new changes, run benchmark loop and compare results.

The gprof profiler was used long before 1993. It dates back to 1982.

I did game engine dev professionally in 1994 (and non-professionally before that). We profiled both time and memory use, using GCC and gprof for function-level profiling, recording memory allocation statistics by type and pool (and measuring allocation time), microbenchmarking the time spent sending commands to blitters and coprocessors, visually measuring the time in different phases of the frame rendering loop to 10-100 microsecond granularity by toggling border or palette registers, measuring time spent sorting display lists, time in collision detection, etc.

You might regard most of those as not what you mean by profiling, but the GCC/gprof stuff certainly counts, as it provides a detailed profile after a run, showing hot functions and call stacks to investigate.

It's true that most of the time, we just changed the code, ran the game again and just looked at the frame rate or even just how fluid it felt, though :-)

But was that in Watcom? I don't think gcc was on DOS until DJGPP v1 which was...1992? I don't remember if gprof was ported. iD did use DJGPP for Quake in 1996.

I'm guessing they used gcc on NeXT but profiling that platform probably didn't make much sense, different compiler, different CPU, different OS...

The game was written on a TurboColor which had a Motorola 68030 (?) that ran at 33MHz and supposedly only ran at 15FPS (probably as slow as a 386DX/33 at the time)

Watcom also had a profiler back then.

Yes, I remember using it in the early 90s.

I was a game engine dev at the same time. We definitely profiled heavily. Microsoft had a profiler of some sort, and I believe we had a third party one too.

I was profiling my code in the early nineties. Sure, I created primitive profiling tools on my own, but regardless.

While 486 AGI stalls were trivial, especially Pentium changed the game with its U and V pipes. You could no longer trivially eyeball what code is faster. Profiling was a must.

Heck, I even "profiled" my C64 routines in the eighties by changing the border color. You could clearly visually see how long your code takes to execute.

I'm currently at the second job in my life where updating the progress bar takes up a tremendous percentage of the overall performance. Because our "engineers" have never used a profiler. At a large international tech giant :(

I do understand it though, at bigger companies you're less likely to want / need to worry about smaller things. Of course, I'm willing to bet money that they implemented a progress bar themselves instead of using an off-the-shelf one.

MFC Progress bar. Like it's 1999

Win32 already had a stock progress bar control in 1999, though. ~

He ported the optimization from the Crispy Doom fork. Since this is one of the first changes in the repo I bet that this was a known issue at the time.

Back at the turn of the century we found that a performance sensitive part of our WIN32 app was adversely affected by reading a setting from an ini file - in Windows 2000, it was significantly slower than on earlier versions of Windows. The setting was just to determine whether to enable logging for that particular part of the app.

Ironically, it was rumoured Monster Hunter Wilds gets a performance boost if you fix a typo in an .ini file (https://steamcommunity.com/app/2246340/discussions/0/5962682...?), but that was debunked (the typo is restored when reopening the game, the .exe uses the same typo so it's not that the wrong value is being read).

While this gives an impressive boost in performance, it also means that frametimes are around 10% longer when the status bar has to be updated.

Overall this can mean that in some situations the game feels not as smooth as before due to these variations.

Essentially when considering real time rendering the slowest path is the most critical to optimize.

Yep, in a real situation the player would be constantly moving around collecting hp/ammo/weapon, losing health/ammo to monsters... all these would cause the status bar to be frequently updated.

I don't think the benchmark accounts that.

At one point the bottleneck to the Siri iOS client was rendering the animated glowy ball.

Reply on news.ycombinator.com