undefined | Better HN

0 pointsw_t_payne8y ago0 comments

Yeah. This is a business and management problem, not a programming problem. If the business wanted to impose memory and compute budgets for different parts of the program, they could. This is what happens in aerospace and automotive when you have more than one program sharing a processor.

0 comments

agentultra8y ago

It happens in game development when you're targeting resource-constrained hardware consoles.

It can happen in web development as well if you're working on a disciplined backend team that cares about designing for request latency and concurrency.

But often scrappy startups don't have the time or money to care about those things. It's more about product fit and keeping customers happy to keep the money coming in.

I personally don't use that excuse and design everything I can with a budget in mind. It's a nice constraint to have an upper bound on response time. Forces you to pick your battles.

noir_lord8y ago

My targets depend on context but I like client side stuff to be done in under 100ms since that was the limit for a human to feel like the interface is 'instant' I learnt at college.

There a bunch of tricks you can pull to give that impression even when you have to go over that limit.

These days I'm lucky, I only work on an internal web app that is almost entirely served over gig ethernet.

j / k navigate · click thread line to collapse