- 🇬🇧United Kingdom catch
We can just keep reducing the number of database queries required to serve a page, in issues like 📌 Entity lazy multiple front loading Active .
On #324313: Load multiple nodes and terms at once → we benchmarked a front page with 30 nodes, with and without the node_load() select query converted to dbtng. http://drupal.org/node/324313#comment-1128706 has the benchmarks and an example patch.
It turns out that db_select() adds ~1ms of processing each time the function is called compared to the current code. When loading a single node this is only about a 1-2% hit, - but on a front page with 30 nodes, it adds 30ms to the processing time - on my machine that page can take about 230ms to load, so it's about a 6-7% hit. Not so good. If the multiple load patch goes in, then it won't be a problem for node queries - but as we convert more queries which are run mulitple times per page request to dbtng we could notice a slowdown.
Since the same query is being built each time in this case, I'm wondering if we could some how cache the built query - this would need to be keyed by something, since obviously there's nothing stopping the same function being called with different arguments on the same page request. No ideas as to how, but opening this issue so the information doesn't get lost.
Closed: outdated
11.0 🔥
database system
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
We can just keep reducing the number of database queries required to serve a page, in issues like 📌 Entity lazy multiple front loading Active .