4 ms·

I’m not sure why you thought I meant code clarity and not performance? It’s clear in all cases the correct SQL query will be more performant. Confused at what

I’m not sure why you thought I meant code clarity and not performance? It’s clear in all cases the correct SQL query will be more performant. Confused at what you’re evening trying to say here. Are you suggesting that 100 lines of application layer code is easier to understand than 15 lines of SQL?

airstrike 4mo ago
The correct SQL query will be more performant than what? The correct ORM call will build the same correct SQL query. ORM is ultimately SQL
- hatefulheart 4mo ago
  So there is no CPU cycles for the ORM itself? That’s free?
  - airstrike 4mo ago
    It's 2026. CPU goes brrr. It's absolutely trivial compared to the query execution time.
    - sgarland 4mo ago
      Profile your code sometime; I assure you, with a properly indexed query, the actual query time is insignificant compared to everything else, unless your app is Rust, C, Nim, etc. The overwhelming majority of OLTP queries I see running on massive prod systems execute in < 1 msec. More time is spent in network RTT than execution, let alone the ORM parsing the result.
      - nfw2 4mo ago
        1. Network transfer time depends on size of data payload and will basically always dwarf cpu operations unless something is seriously messed up 2. Query performance is dependent on the query and table size. They won't all be < 1msec. Not everything can be an indexed O(1) lookup 3. Generally speaking, network RTT and query performance is going to dwarf time for ORM to parse the result 4. A raw SQL driver ALSO needs to parse the result if you want to do anything with the data in the general purpose language
nfw2 4mo ago
1. Because you referred to lines of code as the way to suggest SQL is obvious better, not performance 2. No, my point was that talking about code clarity was a distraction because to talk about lines of code as a determinant of performance is clearly wrong. 3. Tangentially, yes, if some behavior takes 100 lines of general purpose code to express, I would rather read it in the general purpose language than in SQL even if the SQL was fewer lines. It's hard to imagine why this would ever be the case though.

airstrike 4mo ago

The correct SQL query will be more performant than what? The correct ORM call will build the same correct SQL query. ORM is ultimately SQL

hatefulheart 4mo ago
So there is no CPU cycles for the ORM itself? That’s free?
- airstrike 4mo ago
  It's 2026. CPU goes brrr. It's absolutely trivial compared to the query execution time.
  - sgarland 4mo ago
    Profile your code sometime; I assure you, with a properly indexed query, the actual query time is insignificant compared to everything else, unless your app is Rust, C, Nim, etc. The overwhelming majority of OLTP queries I see running on massive prod systems execute in < 1 msec. More time is spent in network RTT than execution, let alone the ORM parsing the result.
    - nfw2 4mo ago
      1. Network transfer time depends on size of data payload and will basically always dwarf cpu operations unless something is seriously messed up 2. Query performance is dependent on the query and table size. They won't all be < 1msec. Not everything can be an indexed O(1) lookup 3. Generally speaking, network RTT and query performance is going to dwarf time for ORM to parse the result 4. A raw SQL driver ALSO needs to parse the result if you want to do anything with the data in the general purpose language

nfw2 4mo ago

1. Because you referred to lines of code as the way to suggest SQL is obvious better, not performance 2. No, my point was that talking about code clarity was a distraction because to talk about lines of code as a determinant of performance is clearly wrong. 3. Tangentially, yes, if some behavior takes 100 lines of general purpose code to express, I would rather read it in the general purpose language than in SQL even if the SQL was fewer lines. It's hard to imagine why this would ever be the case though.