Ticket #5303 (closed defect: fixed)

Opened 8 months ago

Last modified 4 months ago

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

Reported by: MartijnD Assigned to: anonymous
Priority: normal Milestone: 2.5
Component: General Version: 2.5
Severity: normal Keywords: has-patch
Cc: davidb@panix.com

Description

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 ;-)

Attachments

5303_pages.diff (5.7 kB) - added by hailin on 12/12/07 02:40:41.
patch file

Change History

11/01/07 16:14:22 changed by ryan

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

11/01/07 16:16:50 changed by foolswisdom

Relates to #5303?

11/01/07 16:37:44 changed by foolswisdom

Gah, relates to 3614?

11/01/07 17:12:47 changed by besonen

  • cc set to davidb@panix.com.

12/10/07 21:25:00 changed by mdawaffe

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.

12/11/07 15:57:58 changed by hailin

  • status changed from new to closed.
  • resolution set to fixed.

Let N = number of pages The original algorithm takes O(Nx) 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.

12/11/07 15:58:54 changed by hailin

  • status changed from closed to reopened.
  • resolution deleted.

12/11/07 16:15:24 changed by lloydbudd

  • keywords set to has-patch.
  • priority changed from low to normal.
  • version set to 2.4.
  • type changed from task to defect.
  • milestone changed from 2.5 to 2.4.

12/11/07 21:06:58 changed by hailin

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.

12/12/07 02:40:41 changed by hailin

  • attachment 5303_pages.diff added.

patch file

12/14/07 06:20:43 changed by ryan

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

01/07/08 23:56:22 changed by thee17

  • status changed from reopened to closed.
  • resolution set to fixed.

01/08/08 00:18:30 changed by lloydbudd

  • status changed from closed to reopened.
  • resolution deleted.

re-opening, leaving for ryan to close.

02/26/08 09:37:10 changed by ryan

  • status changed from reopened to closed.
  • resolution set to fixed.

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