"Manage > Pages" becomes very slow with hundreds of pages

[MartijnD]

Apologies if this has been mentioned before, I couldn't find a relevant related bug.

I am currently building a prototype blog / content site that has several hundreds of "Pages"; and things have slown down a lot. With just over 250 pages, generation of "Manage > Pages" takes over 30 seconds, which causes PHP time out errors on the server.

Some profiling shows that most time is spend in:

\wp-admin\includes\template.php 166: function page_rows()

The code for hierarchal display is very inefficient, as it loops over and over the full set of posts to check if a post and a parent are related.

180: if ( $hierarchy && ($post->post_parent != $parent) ) 181: continue;

Forcing $hierachy to false reduces the page creation time to 7-8 seconds. Still not great, it should be possible to do this in < 2 seconds.

Please take this as suggestion for improvement.

If I have time, I will look into finding a more efficient piece of code -- for now I still have a couple more pages to add ;-)

Yes, that code is awful. Improvements are definitely welcome.

Relates to #5303?

Gah, relates to 3614?

 http://bitsinashortbit.wordpress.com/2007/09/03/first-showcase-of-page-sorting-in-wordpress/

A GSoC student looked at paginating hierarchical content with this problem in mind.

Let N = number of pages The original algorithm takes O(N^{x) where x>=2. That is why it is very slow to display pages when N is large (over 200)}

The proposed new algorithm accepts as input pages array sorted by post_parent, ID ASC.

Then splice the array into two trunks: trunk#1 contains pages whose post_parent is 0 turnk#2 contains pages whose post_parent > 0

For every page is trunk#1, we look into trunk#2 to see if there is a child. If yes, we display the child page, remove the child page, then recursively examine trunk#2 again to see if there are nested pages to be displayed.

We take advantage of the fact that child pages in trunk#2 is sorted by post_parent, And use heuristics to enable us to do minimal lookups needed.

The time complexity is optimal for this problem – it is O(N).

Note that this algorithm depends on the assumption that input pages are sorted on post_parent, ID. I just discovered that current wporg core has another bug which can cause cached pages in query results out of order.

The new patch does not depend on pages being sorted by post_parent,ID. It is a little slower, but still within O(N) complexity. Reviewed by Ryan, Matt.

patch file

(In [6380]) Faster page_rows() from hailin. see #5303

re-opening, leaving for ryan to close.

As good as it gets for now. Resolving as fixed.

that patch may have improved things but with over 7000 pages ( most of them children of one page ) it takes almost 3 minutes to load the page admin.

If no one has a better way of doing this wordpress should offer a no hierarchy display if that's faster. ( maybe include an option in the screen options for this )

After using xdebug I found out that the main problem was the function get_page_children . I modified this function to something similar to the idea from http://core.trac.wordpress.org/changeset/6380 decreased the time to 1 minute. Now it seems like the rest of the time wordpress tries to update the cache with all those 7000 pages. If I just remove the call to update_post_caches in get_posts the load time goes down to 15 seconds. This is finally acceptable . Why does it need to update the cache for all pages when they are displayed in admin ?

fast get_page_children

I agree that get_page_children needs some improvement. Currently it's O(N^{2). A better way to improve it is to use a similar algorithm used in walker class. I will take a shot at this.}

mihai & hailin really good info! Please open a new ticket referencing this one, as this ticket resulted in code being checked in to a specific release, and things get messy if reopening for anything but a regression.

new ticket created in #10852

mihai: You are welcome to run your 7000 pages example again with #10852 patch.