[wp-hackers] 2.next - faster

[Sebastian Herp]

Speeding things up in 2.next would be nice. Making the function 
"current_time()" pluggable (overwriting it with something using the 
value from the following plugin), together with a plugin like the one 
found here (http://txfx.net/files/wordpress/post-query-accelerator.phps) 
would greatly improve the chance that a query can be cached by mysql 
itself. I did this on a blog and the overall time needed for queries is 
now 30ms if they are all in the mysql cache which is the case most of 
the time!!!

However, this is not the main time eater on my setup. It's mainly the 
php code execution. Wordpress (always on my server and speaking of the 
frontpage) takes 150 to 200 ms to get to the point where it actually 
outputs html. The other big thing is the content loop. Formatting every 
posting each time takes a while. Getting categories and other 
information also eats some milliseconds. Summed up the content display 
stuff takes around 300 ms to execute.

So it's nearly 500 ms for code execution version 30 ms for mysql queries 
... fix the code I say :-) We can savely assume that hosters use 
powerful hardware with caches everywhere. They would be stupid not to ...

What needs to be done to improve Wordpress' performance (in my opinion)?
1. don't use now() or aquivalents in any query! That one should be core 
and not solved with a plugin!
2. find out what takes so long before content is displayed (it's not a 
sql query!)
3. don't filter the content of posts/comments each time they are 
displayed, instead do it on updates of the content only (the columns for 
that exist in the database) This should also be core and not solved with 
a plugin!
4. fix the content loop! The  posts array should include all necessary 
information (kategories with names, comment cound, etc) without the need 
for seperate queries or whatever happens in those getter-functions that 
lets them eat away so many precious milliseconds.
5. encourage plugin authors of popular plugins to do some performance 
tuning, too ;-)

Greetings,
Sebastian

Scott johnson wrote:
> Faster, imho, involves tradeoffs at this point. My gut just on web apps is
> that faster means "look hard at the SQL".  For example I learned TONS about
> mysql scaling at Feedster that I think is applicable but it starts to get
> specialized like memcache support, write versus read servers, etc.,
> seriously playing with your table structure, etc.
>
> Faster in what environment???  I'm happy to contribute ideas but given the
> spectrum of sites WP runs on this question has major ramifications
>
> Scott
>
>