8 ms·
But even if we did it in this naive way, the total execution time is still a very reasonable (48 3 ms) + 260 ms = 404 ms* I can't read things like this and av
by pj 17y ago
But even if we did it in this naive way, the total execution time is still a very reasonable (48 3 ms) + 260 ms = 404 ms*
I can't read things like this and avoid wondering why people keep reading him. He is so wrong so often I ... it's just beyond me.
Query execution time is just one part of performance. You still have to create the connection and transfer all the data across the wire. Sending N records in 1 big package is much more efficient than sending N+1 records in individual packages.
Run a performance measure on the actual code execution and I am almost positive you'll get worse performance than would be indicated by your query execution times alone.
From now on, I'm flagging every codinghorror post.
- smokinn 17y agoIt really depends though. If you're using mysql with myisam tables you can easily come up with a sequence of events that lead to N+1 records being much faster due to table locking issues, especially when joins start getting involved. In that case if you can split your query into N+1 requests by primary key and avoid the join that locks both (or worse, many) tables for a little while it'll be much smoother and faster in production. Now, of course, if you can do that you really should be thinking about memcached and/or a key/value store with possibly a distributed index rather than a relational db anyway.
- fatdog789 17y agoI wouldn't go as far as flagging every codinghorror post...I would limit it just the ones that are related to actual programming code/coding paradigms...which is admittedly almost all of them.