How is UTW too inefficent? Not arguing, just curious as to what that means, exactly. If you don’t define “efficent”, then you’ll get poor responses. 🙂
Without opening it up and running Xdebug on it — I was able to see a 300% performance increase after disabling the plugin.
While the plugin was enabled I was constantly getting script timeouts reported by PHP.
The thing’s a beast, at 4500+ lines of code, it’s a beast of a plugin.
UTW was discussed on WP-Hackers in the recent past, here’s the link:
http://www.nabble.com/Thoughts-on-Ultimate-Tag-Warrior-t2208029.html
Lines of code is a poor way to gauge plugin efficency. A lot of that code is unused, just optional functions you can use or not use. And if you don’t use them, then they really don’t affect performance at all.
I don’t doubt your numbers, but I’ve not seen any kind of major spike on my systems from using UTW.
Running WPMU makes a big difference as the performance hit from one blog is exponentially raised as it’s applied to a network of WPMU blogs … so if your blog’s slow down or spike is only 10% … which is fine … it affects my network over 300%, which is horrible.
Regardless of whether or not the code is “used” it still has to be executed, which many PHP programmers know, often takes more time then the execution itself.
So the compile time + memory trade off (nearly 300K of RAM per blog) was enough for me to scrap it and once I did, the results were clear, it was a hog and a half.
PS – I still use UTW on my personal blog. 😉
Running WPMU makes a big difference as the performance hit from one blog is exponentially raised as it’s applied to a network of WPMU blogs … so if your blog’s slow down or spike is only 10% … which is fine … it affects my network over 300%, which is horrible.
Sorry, but that’s total nonsense. You may have more hits, but this does not affect the percentage of performance impact of any given piece of code. You’re not running 30 blogs. You’re running one blog with 30 different viewpoints. That’s the whole point of WPMU.
Regardless of whether or not the code is “used” it still has to be executed, which many PHP programmers know, often takes more time then the execution itself.
No, it does not have to be executed. It has to be parsed and compiled into intermediate code. While the most naive implementation would require some overhead for having the code in there, a more intelligent PHP processor, like Zend Optimizer or Alternative PHP Cache (APC) would actually cache the resulting intermediate code for later execution between client communication sessions. Implementing JIT compiling would be a good approach too, but I’m not aware of any PHP implementation that has done that yet.
Anyway, if the time compiling the PHP is your problem, then removing code isn’t the solution. The solution is to make it stop compiling all the time. If you’re running a large site, you really need to be using APC or one of the other PHP optimizers. Especially if CPU time is a big concern. APC is free. http://pecl.php.net/package/APC
Since you’re willing to modify code, why not just pare down the UTW plugin to suit your needs? Sure beats starting from scratch or starting with an inferior plugin.
