5 ms·

> Most people, most of the time, doing most web work, are so thoroughly outclassed on speed by their web framework and server that the speed of their choice is

by dlisboa 11mo ago

> Most people, most of the time, doing most web work, are so thoroughly outclassed on speed by their web framework and server that the speed of their choice is irrelevant. Which means they should be selecting based on all the other relevant features. I disagree with that as the choice of framework doesn't impact just the request/response lifecycle but is crucial to the overall efficiency of the system because they lead the user down a more or less performant path. Frameworks are not just HTTP servers. Choosing a web framework also marries you to a language, hence the upper ceiling of your application will be tied to how performant that language is. Taking the article's example, as your application grows and more and more code is in the hot path you can very easily get into a space where your requests that took 50ms now take 500ms.

giancarlostoro 11mo ago
You can also squeeze performance out of most languages by knowing the bottlenecks and working around them. Even Go you can squeeze performance out of if you really need to and want to.
- immibis 11mo ago
  Go is far from the slowest language even though it has GC.
  - actionfromafar 11mo ago
    If we allow for warmup, Java is pretty fast for many workloads. https://madnight.github.io/benchmarksgame/go.html https://madnight.github.io/benchmarksgame/go.html
    - ecshafer 11mo ago
      Java is very fast. You just have to account for the amount of absolutely terrible written Java code full of 6 levels of inheritance, 6 levels of nested loops and AbstractFactoryFactoryFactoryProviderImpls out there to slow it down. I swear I have seen so much Java code that in the name of "abstraction" and "maintainability" they would take x + y and turn it into 8 classes and method calls.
      - giancarlostoro 11mo ago
        Yeah, I have been disenfranchised by this style of programming. Its why I prefer languages like Python, when you use objects / classes as needed.
        ecshafer 11mo ago
        Modern Java, obviously is still objects everywhere, but the deep inheritance is really discouraged. Interfaces with default implementations, records, lambdas. There is just a lot that has moved the culture away from that style of programming, but not all places have moved.
        zahlman 11mo ago
        It's a shame that this Java culture left its mark on the Python standard library (notably, in `unittest` and `logging`; the framework for text encodings is also highly boilerplate-y) and a fair bit of the ecosystem (pip has some classes like `class ConfiguredBuildBackendHookCaller(BuildBackendHookCaller)` in its own code, to say nothing of what's vendored) already, though.
        giancarlostoro 11mo ago
        Its a shame the over-abstraction culture was so strong that Go did not implement generics until over a decade later because they didn't want all the associated headaches. I know both are somewhat different, but it feels like it all came together as "let's not do that, its a nightmare" essentially.
      - marginalia_nu 11mo ago
        I think that school of Java is on the way out. Since it's absurdly backward compatible there's a lot of factoryfactory code still lingering, but I don't see it being written a lot. Though there are a lot of unfortunate "truths" in Java programming that seems to encourage malignant abstraction growth, such as "abstractions are free", and "C2 will optimize that for you". It's technically kinda mostly true, but you write better code if you think polymorphism is terribly slow like the C++ guys tend to do.
    - igouy 11mo ago
      Beware. That is not the benchmarks game website. Here's the current benchmarks game website — https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Here are some startup warmup measurements — https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbodyinprocess.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - jerf 11mo ago
    I like to characterize it as "the slowest language of the fastest class of languages". In general other compiled languages are faster, though generally we're talking 2 or 3 times at the most (Go doesn't optimize very hard but the language defaulting to unboxed values made up for a substantial proportion of that versus more box-heavy compiled languages), but Go is "generally" faster than nearly all non-compiled languages. "Generally" here means "on general code"; JIT languages can definitely outdo Go on heavily numeric code, even in scripting languages, because JITs are very good at that, but the sort of "general" code that isn't obviously numeric will be faster in Go than any non-compiled language. This sort of complicated analysis doubles as another example of the difficulty of context-free "fast" and "slow" labels. Is Go "fast"? For a general programming language, yes, though not the fastest. If you reserve "fast" for C/C++/Rust, then no it is not fast. Is it fast compared to Python, though? Yes, it'll knock your socks off if you're a Python programmer even with just a single thread, let alone what you can do if you can get some useful parallel processing going.
    - igouy 11mo ago
      > context-free "fast" and "slow" labels Be specific. Ask: Faster than what … to do what?
  - pdimitar 11mo ago
    @jerf beat me to it but indeed Golang is one of the very slowest compiled languages out there. I have an okay idea why but I wish someone there made a more serious effort to accelerate it at least by a factor of 2x. I hate having to mull over the pros and cons of Rust for the 89th time when I know that if I make a service in Golang I'll be called in 3 months to optimise it. But multiple times now I have swallowed the higher complexity and initial slow building curve of Rust just so I don't have to go debug the mess that a few juniors left while trying to be clever in a Golang codebase.
jerf 11mo ago
You can, without loss of generality, simply insert "holding the language constant" if you like into the essay without losing the point I am trying to make, where the question of what language to choose is mostly orthogonal to the point I'm making in that particular essay. In other contexts I'm a huge proponent of validating that your language is fast enough. There's a constant low-level flow of "we switched from X to Y and got Z% speedup" articles on HN, and while the details of the articles are often quite interesting, with rare exceptions I find that I read them and conclude that it was an error to ever have used X in the first place and the team should have been able to tell immediately that it wasn't going to be a good solution. Exceptions include "we were a startup at the time and experienced rather substantial growth" and the rare cases where technology X is just that much faster for some particular reason... though probably not being a "scripting language" as nowadays I'm not particularly convinced they're all that much faster to develop with past the first week, but something more like "X had a high-level but slow library that did 90% of what we needed but when we really, really needed that last 10% we had no choice but to spend person-years more time getting that last 10% of functionality, so we went with Y anyhow for the speed".
- dlisboa 11mo ago
  You make an assumption here that the software is also constant or static. > There's a constant low-level flow of "we switched from X to Y and got Z% speedup" articles on HN, and while the details of the articles are often quite interesting, with rare exceptions I find that I read them and conclude that it was an error to ever have used X in the first place and the team should have been able to tell immediately that it wasn't going to be a good solution. The language X was probably a good solution at first. Then the company started to increase its product surface or acquired enterprise customers. Now you have new workloads that were not considered and the language is no longer suited for it. Most likely a decision is made to not introduce a second language to the company just for these new workloads as that complicates the architecture, not to mention hiring and managing, so you stay with language X and try to make do. Now you have language X doing more than it is suited for and response times often increase due to that. This isn't really a case of startup growing pains, just that software itself cannot know ahead of time every application it'll have. You can choose a "mostly fast for all use cases" language and bet that your applications will fit those general use cases, this means you win small but also lose small.
yyx 11mo ago
Agreed, some languages and frameworks have trouble scaling https://news.ycombinator.com/item?id=45950542 https://news.ycombinator.com/item?id=45950542
ndriscoll 11mo ago
My immediate reaction to seeing > It is completely normal for web requests to need more than 5 milliseconds to run. If you’re in a still-normal range of needing 50 milliseconds to run, even these very slow frameworks are not going to be your problem. Is that it apparently does make a huge difference. At least doing CRUD web stuff, my calibration for Scala (so pretty high-level functional code) is to expect under 1 ms of CPU-time per request. The only time I've ever seen something in the 50-100 ms range was when working with Laravel. 5 ms is what I'd expect as the total response time for e.g. a paginated API returning 100+ records with a bunch of optional filters.

by dlisboa 11mo ago

giancarlostoro 11mo ago

You can also squeeze performance out of most languages by knowing the bottlenecks and working around them. Even Go you can squeeze performance out of if you really need to and want to.

immibis 11mo ago
Go is far from the slowest language even though it has GC.
- actionfromafar 11mo ago
  If we allow for warmup, Java is pretty fast for many workloads. https://madnight.github.io/benchmarksgame/go.html https://madnight.github.io/benchmarksgame/go.html
  - ecshafer 11mo ago
    Java is very fast. You just have to account for the amount of absolutely terrible written Java code full of 6 levels of inheritance, 6 levels of nested loops and AbstractFactoryFactoryFactoryProviderImpls out there to slow it down. I swear I have seen so much Java code that in the name of "abstraction" and "maintainability" they would take x + y and turn it into 8 classes and method calls.
    - giancarlostoro 11mo ago
      Yeah, I have been disenfranchised by this style of programming. Its why I prefer languages like Python, when you use objects / classes as needed.
      - ecshafer 11mo ago
        Modern Java, obviously is still objects everywhere, but the deep inheritance is really discouraged. Interfaces with default implementations, records, lambdas. There is just a lot that has moved the culture away from that style of programming, but not all places have moved.
        zahlman 11mo ago
        It's a shame that this Java culture left its mark on the Python standard library (notably, in `unittest` and `logging`; the framework for text encodings is also highly boilerplate-y) and a fair bit of the ecosystem (pip has some classes like `class ConfiguredBuildBackendHookCaller(BuildBackendHookCaller)` in its own code, to say nothing of what's vendored) already, though.
        giancarlostoro 11mo ago
        Its a shame the over-abstraction culture was so strong that Go did not implement generics until over a decade later because they didn't want all the associated headaches. I know both are somewhat different, but it feels like it all came together as "let's not do that, its a nightmare" essentially.
    - marginalia_nu 11mo ago
      I think that school of Java is on the way out. Since it's absurdly backward compatible there's a lot of factoryfactory code still lingering, but I don't see it being written a lot. Though there are a lot of unfortunate "truths" in Java programming that seems to encourage malignant abstraction growth, such as "abstractions are free", and "C2 will optimize that for you". It's technically kinda mostly true, but you write better code if you think polymorphism is terribly slow like the C++ guys tend to do.
  - igouy 11mo ago
    Beware. That is not the benchmarks game website. Here's the current benchmarks game website — https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Here are some startup warmup measurements — https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbodyinprocess.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- jerf 11mo ago
  I like to characterize it as "the slowest language of the fastest class of languages". In general other compiled languages are faster, though generally we're talking 2 or 3 times at the most (Go doesn't optimize very hard but the language defaulting to unboxed values made up for a substantial proportion of that versus more box-heavy compiled languages), but Go is "generally" faster than nearly all non-compiled languages. "Generally" here means "on general code"; JIT languages can definitely outdo Go on heavily numeric code, even in scripting languages, because JITs are very good at that, but the sort of "general" code that isn't obviously numeric will be faster in Go than any non-compiled language. This sort of complicated analysis doubles as another example of the difficulty of context-free "fast" and "slow" labels. Is Go "fast"? For a general programming language, yes, though not the fastest. If you reserve "fast" for C/C++/Rust, then no it is not fast. Is it fast compared to Python, though? Yes, it'll knock your socks off if you're a Python programmer even with just a single thread, let alone what you can do if you can get some useful parallel processing going.
  - igouy 11mo ago
    > context-free "fast" and "slow" labels Be specific. Ask: Faster than what … to do what?
- pdimitar 11mo ago
  @jerf beat me to it but indeed Golang is one of the very slowest compiled languages out there. I have an okay idea why but I wish someone there made a more serious effort to accelerate it at least by a factor of 2x. I hate having to mull over the pros and cons of Rust for the 89th time when I know that if I make a service in Golang I'll be called in 3 months to optimise it. But multiple times now I have swallowed the higher complexity and initial slow building curve of Rust just so I don't have to go debug the mess that a few juniors left while trying to be clever in a Golang codebase.

jerf 11mo ago

You can, without loss of generality, simply insert "holding the language constant" if you like into the essay without losing the point I am trying to make, where the question of what language to choose is mostly orthogonal to the point I'm making in that particular essay. In other contexts I'm a huge proponent of validating that your language is fast enough. There's a constant low-level flow of "we switched from X to Y and got Z% speedup" articles on HN, and while the details of the articles are often quite interesting, with rare exceptions I find that I read them and conclude that it was an error to ever have used X in the first place and the team should have been able to tell immediately that it wasn't going to be a good solution. Exceptions include "we were a startup at the time and experienced rather substantial growth" and the rare cases where technology X is just that much faster for some particular reason... though probably not being a "scripting language" as nowadays I'm not particularly convinced they're all that much faster to develop with past the first week, but something more like "X had a high-level but slow library that did 90% of what we needed but when we really, really needed that last 10% we had no choice but to spend person-years more time getting that last 10% of functionality, so we went with Y anyhow for the speed".

dlisboa 11mo ago
You make an assumption here that the software is also constant or static. > There's a constant low-level flow of "we switched from X to Y and got Z% speedup" articles on HN, and while the details of the articles are often quite interesting, with rare exceptions I find that I read them and conclude that it was an error to ever have used X in the first place and the team should have been able to tell immediately that it wasn't going to be a good solution. The language X was probably a good solution at first. Then the company started to increase its product surface or acquired enterprise customers. Now you have new workloads that were not considered and the language is no longer suited for it. Most likely a decision is made to not introduce a second language to the company just for these new workloads as that complicates the architecture, not to mention hiring and managing, so you stay with language X and try to make do. Now you have language X doing more than it is suited for and response times often increase due to that. This isn't really a case of startup growing pains, just that software itself cannot know ahead of time every application it'll have. You can choose a "mostly fast for all use cases" language and bet that your applications will fit those general use cases, this means you win small but also lose small.

yyx 11mo ago

Agreed, some languages and frameworks have trouble scaling https://news.ycombinator.com/item?id=45950542 https://news.ycombinator.com/item?id=45950542

ndriscoll 11mo ago

My immediate reaction to seeing > It is completely normal for web requests to need more than 5 milliseconds to run. If you’re in a still-normal range of needing 50 milliseconds to run, even these very slow frameworks are not going to be your problem. Is that it apparently does make a huge difference. At least doing CRUD web stuff, my calibration for Scala (so pretty high-level functional code) is to expect under 1 ms of CPU-time per request. The only time I've ever seen something in the 50-100 ms range was when working with Laravel. 5 ms is what I'd expect as the total response time for e.g. a paginated API returning 100+ records with a bunch of optional filters.