"You're quick to toss out unsupported assertions: e.g. calling the ORM awful just sounds naive"
I can assure my assertions are based by a lot of benchmarking of a Django project that heavily depended on the ORM. And it's not even about the quality of the queries, Postgres was eating them like hot cakes, but the ammount of queries itself was making it slow. Even for things like user_token.delete() (this was an open source project in Django that we were adapting)
Oh sure, I don't recommend the first step of optimization to be switching to Jinja2, Django templates are fine for 99% of cases. But in my case, Django templates were being used in a very specific way (which btw was done in the original project, that is, not by me) which was very slow (think 1s per page, and that's without querying the db!)
I would argue that the main problem is so many queries: rather than arguing about ORM dispatch speed it's almost always better to make fewer queries and/or retrieve less data as you can cut out a ton of unavoidable overhead intrinsic to shipping a query to another process (possibly on another system), executing it and handling the results. ORM improvements can only address either end of that process.
Similarly, 1s to render a template sounds rather unusual - if that's not just something like not using the cached loader on a slow filesystem it's screaming for logic to move into the view or a template tag.
I will also note in both cases these started out as general assertions which were then qualified to refer to specific edge cases. Again, without describing the exact code being benchmarked it's a disservice to through out performance advice to people who might take it as a general rule rather than understanding that it's unlikely to be a significant problem for most users.
>> "I would argue that the main problem is so many queries: rather than arguing about ORM dispatch speed it's almost always better to make fewer queries"
In Python there aren't many queries! That's the issue!
Let me explain better. Django ORM is converting a few lines (and sometimes ONE - like user_token.delete() ) of python to tens of queries. These tens of queries take around 200ms (or more) because each query takes around 3ms/10ms
user_token.delete() was taking 300ms (I wish I was kidding)
"Similarly, 1s to render a template sounds rather unusual - if that's not just something like not using the cached loader on a slow filesystem it's screaming for logic to move into the view or a template tag."
No, not cached loader, not slow filesystem. It's a for with an inner include.
If a simple delete call is generating more than one query, it's either oddly customized or you have a ton of related models which need to be updated to adjust the cascade behavior:
“No, not cached loader, not slow filesystem. It's a for with an inner include.”
With a lot of loops - again, not common for most web apps (who wants a 5mb HTML page?). You should be able to avoid this by using a custom template tag to load once and render many times.
I can assure my assertions are based by a lot of benchmarking of a Django project that heavily depended on the ORM. And it's not even about the quality of the queries, Postgres was eating them like hot cakes, but the ammount of queries itself was making it slow. Even for things like user_token.delete() (this was an open source project in Django that we were adapting)
Oh sure, I don't recommend the first step of optimization to be switching to Jinja2, Django templates are fine for 99% of cases. But in my case, Django templates were being used in a very specific way (which btw was done in the original project, that is, not by me) which was very slow (think 1s per page, and that's without querying the db!)