3 ms·

Don't forget the 90% of the processing time that it's waiting for a DB response

ilyt 4y ago
Eh, that heavily depends on language and dataset you're working with. I've seen "simple" data with some fat thing like RoR on top of it having 10x the latency of the underlying database after all the ORMing.
- ajmurmann 4y ago
  Most of my experience with this actually comes from RoR. I worked on one so where rendering slowed everything down to a grind, but more often than not it was making Yu noptimized queries, too many queries, inefficient calls to other services. I used to work as a consultant, so this was true for quite a few apps. However, I also usually was the person most interested in relational databases and my view might have selection bias.
- whstl 4y ago
  I have a similar experience. Also, for the longest time Rails was also incredibly slow at generating JSON, of all things. JBuilder [1] was a few orders of magnitude slower than using .to_json directly or other libraries. [1] https://github.com/rails/jbuilder https://github.com/rails/jbuilder, maintained by DHH and the Rails team. AFAIR, the "official" JSON serialization DSL.
FridgeSeal 4y ago
I’d like to work in one of these teams/products where the database is the bottleneck. Basically everywhere I’ve worked, I’ve had to work with backends that have been foot-draggingly slow compared to the actual database.
- ajmurmann 4y ago
  Just work with some folks who don't know basic query optimization
TeMPOraL 4y ago
Except when it isn't. I remember an article making rounds the other day, that claimed the whole "most software spend most time waiting on I/O" common wisdom is no longer true, as most software these days is CPU-bound, and a good chunk of that is parsing JSON.
- saagarjha 4y ago
  For pure compute most software is memory bandwidth bound and for large applications I/O is generally still a problem given the costs of flash.
  - TeMPOraL 4y ago
    > For pure compute most software is memory bandwidth bound This is related, though. While the final leaps of performance often come from using more memory to make CPU work less, in my experience, most of the performance-problematic code wastes both CPU and memory, and meaningfully faster alternatives end up using less of both. Either way, from the end-user perspective, I tentatively agree with the article I mentioned (but don't have a link handy, sorry) - most of the software I end up using, or see people around me using, is clearly CPU-bound, briefly network I/O-bound (mostly web apps), and rarely local I/O-bound. EDIT: I guess the caveat is that end-user software is often spending 99% time doing nothing at all, just waiting for user input. But that bit doesn't matter - what matters is how fast it reacts to the input once the user starts providing it. This is where a lot of software suddenly gets CPU-bound (or net IO-bound, if doing something stupid).
darkwater 4y ago
Yes, because of some clean and readable way (for the developer) the code uses to interact with the DB...

ilyt 4y ago

Eh, that heavily depends on language and dataset you're working with. I've seen "simple" data with some fat thing like RoR on top of it having 10x the latency of the underlying database after all the ORMing.

ajmurmann 4y ago
Most of my experience with this actually comes from RoR. I worked on one so where rendering slowed everything down to a grind, but more often than not it was making Yu noptimized queries, too many queries, inefficient calls to other services. I used to work as a consultant, so this was true for quite a few apps. However, I also usually was the person most interested in relational databases and my view might have selection bias.
whstl 4y ago
I have a similar experience. Also, for the longest time Rails was also incredibly slow at generating JSON, of all things. JBuilder [1] was a few orders of magnitude slower than using .to_json directly or other libraries. [1] https://github.com/rails/jbuilder https://github.com/rails/jbuilder, maintained by DHH and the Rails team. AFAIR, the "official" JSON serialization DSL.

FridgeSeal 4y ago

I’d like to work in one of these teams/products where the database is the bottleneck. Basically everywhere I’ve worked, I’ve had to work with backends that have been foot-draggingly slow compared to the actual database.

ajmurmann 4y ago
Just work with some folks who don't know basic query optimization

TeMPOraL 4y ago

Except when it isn't. I remember an article making rounds the other day, that claimed the whole "most software spend most time waiting on I/O" common wisdom is no longer true, as most software these days is CPU-bound, and a good chunk of that is parsing JSON.

saagarjha 4y ago
For pure compute most software is memory bandwidth bound and for large applications I/O is generally still a problem given the costs of flash.
- TeMPOraL 4y ago
  > For pure compute most software is memory bandwidth bound This is related, though. While the final leaps of performance often come from using more memory to make CPU work less, in my experience, most of the performance-problematic code wastes both CPU and memory, and meaningfully faster alternatives end up using less of both. Either way, from the end-user perspective, I tentatively agree with the article I mentioned (but don't have a link handy, sorry) - most of the software I end up using, or see people around me using, is clearly CPU-bound, briefly network I/O-bound (mostly web apps), and rarely local I/O-bound. EDIT: I guess the caveat is that end-user software is often spending 99% time doing nothing at all, just waiting for user input. But that bit doesn't matter - what matters is how fast it reacts to the input once the user starts providing it. This is where a lot of software suddenly gets CPU-bound (or net IO-bound, if doing something stupid).

darkwater 4y ago

Yes, because of some clean and readable way (for the developer) the code uses to interact with the DB...