The plugin needs to first collect the headers of the post before it can display them in a freely positional toc box. Hence it queries the post/page content unconditionally, but only in singular view (when there’s only a single post/page shown).
There is no other way. Even to scan the content for a “[toc]” shortcode first, it would have to query it nonetheless.
However, the plugin does not do any extra database queries. It processes already retrieved content, so it should not really create any significant overhead in terms of CPU load.
On the other hand, I see little sense in reducing CPU load by all means, “out of principle”. If you have enough CPU power, it would be a waste not to use it. (The opposite extreme is, to reduce CPU load by 100%, you’ll have to stop using the computer.) In my experience, today’s servers all have plenty of CPU power to cope with a couple of dozens, or hundreds, WP plugins.
Thanks Hack. I was just surprised that data wasn’t put together in a cron job or when the post was created.
Reassuring to know the query is so small.
I had to eliminate CPU because I was overpeaking the shared host. Turns out YARPP and Simple Tags were really culprits though; they had terrible and huge queries.
“I was just surprised that data wasn’t put together in a cron job or when the post was created.”
If the plugin would build the TOC when the post is stored, it would have to store that data somehow. Modifying the post before it is stored is problematic in a whole bunch of ways. Hence it would have to store the data in extra database storage, but then it would have to perform an extra query at post render time to retrieve that data, and that would add to CPU load even more. (Database queries are usually amongst the most expensive in terms of performance).
Ah, I knew you were a good coder Hack. That’s reassuring. If only the other guys did their part to use the least-CPU method.
