Hacker News Reader

Comment by paxys | Hacker News Reader

All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms. So sure, if you absolutely must optimize that 30ms call after you have fixed everything else then go ahead, but very few are at that stage or will ever get to that stage. And if you try to optimize that last 5ms at the expense of the much larger issues then you are actually making things worse.

View on HN

> All of the advice in that article isn't going to bring your server latency for an API call down from 1000ms to 30ms, but rather from 30ms to 25ms.

Of course it will.

If your backend service is already suboptimal, and running at 10x worse performance, optimizing that will give you, well, a 10x performance boost.

Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.

Boom. You're operating close to the speed of light.

>Imagine replacing poor in-memory reimplementation of database queries that most graphql servers do with actual opttimised database queries. And a better code on top.

but you are actually talking about optimizing system design, and not reducing virtual functions calls :).

And that the point of this thread: you need to optimize parts that slow you the most.

So no, in most cases optimizing virtual calls won't bring you from 1s to 30ms

Reply on news.ycombinator.com