[wp-hackers] lots of category items
wordpress at zed1.com
Fri Apr 6 09:11:55 UTC 2012
On Fri, Apr 6, 2012 at 01:24, Haluk Karamete <halukkaramete at gmail.com>wrote:
> The question is if the speed concerns you raised in your article warrants
> that we go with one taxonomy and live with the "lots of category items" or
Why don't you just try it? Instead of trying to estimate or predict, why
Take a copy of your live database/site, and run some tests against it with
the actual queries. You can get them by defining define('SAVEQUERIES',
true); in wp-config and then the queries will be in $wpdb->queries. That
array includes the execution time of those queries. There may be enough of
a difference between them to give you your answer straight away. But those
execution times include some WordPress processing time. So you could
perhaps take those queries and run them directly against your database,
(1000 times and take the average or something).
The most important thing about optimising for speed is to measure.
Measuring will tell you whether you even have a problem that needs
optimising, measuring will tell you how big the problem is, and measuring
(often in the form of profiling) will tell you where the problem is.
It is often not where you think. I once sat through a wonderful
demonstration that showed the difference between two pieces of PHP code
that had the same functionality: one did everything in a couple of
extremely complex multi-part statements, and the other made about 9 or 10
nested function calls to do the same thing. The audience, myself included,
assumed the latter would be slower, we guessed by as much as 10%.
The lecturer demonstrated that after a million iterations the total time
diference between the two methods was still less than 10 milliseconds. Yes
the latter method was slower, but the difference was negligible. The
advantage of the slower method was legibility, maintainability,
A few years ago, I managed to stop a multisite ecommerce website (not
WordPress!) serving 10,000s of transactions a day, from grinding to a halt
by *reducing* the amount of memory allocated to the engine! No amount of
logic would have got me to that solution, but measurement did. (It turned
out the Java VM had a poorly coded garbage collector, and the more free
memory it had, the worse it performed!)
Measuring, is the only way to be sure.
More information about the wp-hackers