Just a quick update for those who are following developments for my AZIndex plugin (is there anybody out there… there… there… ?).
Anyway, it looks like I have a viable caching solution almost completed, and the speed improvements are quite gratifying. I have created several test indexes containing over 1100 items and the index pages load anywhere from 4x to 50x faster when they are being cached, depending on the options set for the index.
Obviously indexes with multiple pages see the biggest gains because if you put 1000 items on one index page, the plugin still has to loaded all 1000 items from the database even though they don’t have to be sorted. Even so, a 4x speed improvement is nothing to sniff at. But if you have a large number of items in the index, it’s only natural to have them spread over multiple pages, so in most cases you will see at least a 10x improvement over a non-cached index.
I have added an option to disable caching, but I recommend against using it unless you think you might be having problems with caching, and you can reset the cache from the admin page if necessary.
How does AZIndex know when the cache is out of date? Well, it attaches to the WordPress action hooks which fire when someone saves or publishes a post. Each index maintains a dirty list of posts and pages that have changed since the cache was last rebuilt, and when the index is next display, it checks though its dirty laundry (if you will) to see if the ordering of the items has been affected by the changes, or if a post needs to be removed from or added to the index. If it does find the index needs to be updated, then it will rebuild the cache causing a one-time slower load for one very slightly unlucky user.
Hooking changes to custom fields turned out to be a pain, since there are no definitive hooks for them, and you can change them without having to save the post afterwards. In the end I attach to the Ajax hooks which fire when a user is editing a custom field. That will probably work for 99% of all custom field changes, but if a blog uses another plugin to change custom fields using the function calls, then there is little AZIndex can do to detected those changes. But in the worst case, all the blogger has to do is manually clear the cache once all the changes have been made.
So, be on the lookout for AZIndex v0.5 with full caching support sometime this week, just in time for the holiday weekend.