[wp-hackers] wordpress optimizations

[denis at semiologic.com]

Quoting Podz <podz at tamba2.org.uk>:

> Robert Deaton wrote:
> > I think that a lot of plugins are more of the cause of
> > high overhead than a plain old WordPress.
> >
>
> Matt mentioned this before but more (I thought) in the context of poor
> coding. Anyone prepared to point the finger at bad plugins ? the point
> being of course to make things better rather than blame anyone !
>


Sure:

- stat plugins tend to have overheads when they are not grabbing the 'shutdown'
plugin hook; i've seen stat plugins do insert statements (yuck!) before the
page was fully sent to the user

- data retrieving plugins such as rss aggregators trivially tend to have huge
overheads when they do not cache results often enough and when they do the
caching at the wrong moment (the right moment being 'shutdown', with the
results sent via an iframe, rather than 'init')

- recent [your pick] plugins tend to have huge overheads in 1.5 and lower unless
you stay away from built-in wordpress functions. i've chopped the overhead of my
fuzzy recent plugins by a factor of 5 since the beginning of the week on an
1.5.1 platform, and i think there still is room for a little more optimization.
thus, there is plenty of room to tweak around here

- markdown brings considerable overhead; i presume the same goes for textile,
string-processing, and text to image features and plugins. there's not much you
can do here besides caching.

- my smart link plugin still has a significant overhead. i've significantly
chopped it by doing some caching, by triggering the caching only when
necessary, and by optimizing the regexps. at this point, there's not much more
i can do short of storing aggregate results for future use, and i'd really hate
to do this without triggers, functions and stored procedures

- subscribe to comments brings some overhead, though not anything close to
comparable to markdown. And from mentioning it to Mark, I understand this comes
from the wp workflow: his options have the autoload set to 'yes', yet queries to
the options table still occur


More generally, i'd say wp and plugin overheads comes from:

- An unoptimized/buggy workflow, as in making the same query multiple times,
making a resource hungry action occur at the wrong place (e.g. init, when it
might as well occur in shutdown), or making queries without checking that they
will be useful first (e.g. category caching should only occur when they are
used for the first time)

- Exploring huge object arrays, as in my blog cat listing. -1 number of posts,
in particular could probably signal removing where post_id in ( /* all */ )
clauses, which bring sql overheads in addition to exploring 100+ object arrays

- Using regular expressions and other string formatting operations, which are
resource hungry as a rule; but i think wordpress has better things to
concentrate on

- Not using sql triggers, functions and stored procedures, but then this solely
comes from mysql not being a relevant language to manage a db

Lastly, I'd presume, from watching LightPress at a distance, that parsing big
chunks of source code also brings a non-neglectable overhead. I was quite
surprised to see that LightPress outperformed a WordPress install with
staticize enabled.

http://www.sencer.de/article/1036/wordpress-vs-textpattern---a-quick-performance-benchmark


--
Denis
http://www.semiologic.com

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.