Hacker News Reader

Comment by astrange | Hacker News Reader

Note "faster" is not the only thing to optimize for, and it (wall clock time) is actually a bit unusual as it doesn't represent an exhaustible resource.

That is, if you have a rarely used slow part of the system, that might make it seem unimportant, but not if running it uses all the disk space or drains your phone battery.

Even if that doesn't happen, there are things you can optimize in the unimportant parts - you can optimize them getting out of the way of the rest of the system, like by having smaller code size and not stomping all over caches.

View on HN

> Note "faster" is not the only thing to optimize for

That is very true! I simply think of it first because it is often the biggest problem at my work. One of the extreme exceptions was optimising Wavetale for the Nintendo Switch, where we had to decrease memory usage from over 20GiB to below 3GiB.

> <time> is actually a bit unusual as it doesn't represent an exhaustible resource.

Not in the context of game development, however! There you typically don't care about wall time. Instead, you work towards a set frame rate meaning you have a set slice of time (usually 16.7 or 33.3 ms) to go through the entire game and render loop each time.

> Not in the context of game development, however! There you typically don't care about wall time. Instead, you work towards a set frame rate meaning you have a set slice of time (usually 16.7 or 33.3 ms) to go through the entire game and render loop each time.

I was about to bring a similar example: Some of our really old daily data processing at work might need some attention and optimization in the future, because we're running out of hours in the day. And we haven't found a place we can buy more hours in the day from yet.

If you can run the daily batch processing in parallel, can't you have one batch start at T+0, the next one starts at T+24h, then the first one finishes at T+28h and so on?

Sadly, the resource constraints/setup prevent us from parallelizing this. And the customers of that system expect the data to be processed and available after 24 hours.

In part, it's a somewhat rewarding topic. Thinking about queries, joining a bit differently, adding another index based on new data patterns can cut hours of runtime without incurring further resource cost.

But on the other hand, it's yet another project someone dumped on the floor and we were forced to adopt it "because of the customer". And the second or third project of PD trying to "do it right" is teetering on failure once again. Cron running shell scripts held together with chicken wire and duct tape is too strong of a stack I guess.

That leads to an infinite backlog no ? If you need more than 24h to process 24h of data ?

That may depend on the context and data but you may end the first job at T+28 (runtime of 28 hours) and the second at T+52 (28 hours as well, started at T+24).

If jobs must be executed one after another, then you absolutely create an infinite backlog.

In realtime audio programming, for example, the time budget can be as low as 1.3 ms (64 samples @ 48kHz). And every single missed deadline will manifest as an ugly pop which you will try to avoid at all cost.

This is so true and so often ignored: there can be optimization for space (RAM and or ROM), energy, security, robustness, etc. often they oppose or compete somehow with speed.

Reply on news.ycombinator.com