4 ms·

Django's ORM is beautiful, I can glide through queries using it. It makes SQL a breeze

by animal_spirits 3y ago

LtWorf 3y ago
But is it fast?
- boxed 3y ago
  Fast to develop with? Yes. Fast to run? Well.. no.. it's Python. I personally care much more about development speed and time to market/customer than execution speed. It's good enough for 99% of cases.
  - LtWorf 3y ago
    You're doing queries to a db, the fact that it's python is not your bottleneck
    - hansvm 3y ago
      That's mostly false for a nontrivial fraction of queries in most bigger projects. If your queries are doing sane things (not regularly full table scanning for each customer, ...), little things like datetime conversions as the rows are instantiated in Python easily dwarf the cost of the database (depending on your networking setup and exact queries, perhaps just in throughput instead of latency, but Python will the still at least be the "cost" bottleneck for your app).
      - LtWorf 3y ago
        To convert some dates? Really? Have you benchmarked this?
        hansvm 3y ago
        Yes!! I recently found a 12% overall latency win (_much_ higher in just the datetime code I changed) at $WORK replacing some of the native datetime conversions with something more intelligent, tailored to the specific <redacted work stuff> context at hand.
    - boxed 3y ago
      In that case it doesn't matter if the ORM is "slow". Anyway, I disagree. Sometimes the conversion of raw data from the db to Python objects can be the bottleneck for a view. Of course, almost always when this happens it's not really a problem per se as the view is plenty fast enough.
- asyx 3y ago
  Fast enough. You get enough tools to optimize the queries. Keep in mind that Django is still a web framework. You can go nuts with Django and it starts to feel like maybe raw SQL would have been easier but I've rarely encountered this.
  - LtWorf 3y ago
    In a previous job we were using some ORM for mongodb and writing queries by hand gave massive speed gains.

Django's ORM is beautiful, I can glide through queries using it. It makes SQL a breeze

LtWorf 3y ago

But is it fast?

boxed 3y ago
Fast to develop with? Yes. Fast to run? Well.. no.. it's Python. I personally care much more about development speed and time to market/customer than execution speed. It's good enough for 99% of cases.
- LtWorf 3y ago
  You're doing queries to a db, the fact that it's python is not your bottleneck
  - hansvm 3y ago
    That's mostly false for a nontrivial fraction of queries in most bigger projects. If your queries are doing sane things (not regularly full table scanning for each customer, ...), little things like datetime conversions as the rows are instantiated in Python easily dwarf the cost of the database (depending on your networking setup and exact queries, perhaps just in throughput instead of latency, but Python will the still at least be the "cost" bottleneck for your app).
    - LtWorf 3y ago
      To convert some dates? Really? Have you benchmarked this?
      - hansvm 3y ago
        Yes!! I recently found a 12% overall latency win (_much_ higher in just the datetime code I changed) at $WORK replacing some of the native datetime conversions with something more intelligent, tailored to the specific <redacted work stuff> context at hand.
  - boxed 3y ago
    In that case it doesn't matter if the ORM is "slow". Anyway, I disagree. Sometimes the conversion of raw data from the db to Python objects can be the bottleneck for a view. Of course, almost always when this happens it's not really a problem per se as the view is plenty fast enough.
asyx 3y ago
Fast enough. You get enough tools to optimize the queries. Keep in mind that Django is still a web framework. You can go nuts with Django and it starts to feel like maybe raw SQL would have been easier but I've rarely encountered this.
- LtWorf 3y ago
  In a previous job we were using some ORM for mongodb and writing queries by hand gave massive speed gains.