[wp-trac] [WordPress Trac] #14889: Memory Comparison Broken / WordPress Memory Limit

[WordPress Trac]

#14889: Memory Comparison Broken / WordPress Memory Limit
---------------------------------+-----------------------------
 Reporter:  hakre                |       Owner:
     Type:  defect (bug)         |      Status:  new
 Priority:  normal               |   Milestone:  Future Release
Component:  General              |     Version:  3.0
 Severity:  normal               |  Resolution:
 Keywords:  has-patch 3.2-early  |
---------------------------------+-----------------------------

Comment (by chrisbliss18):

 Here's a new patch that addresses the ideas brought up in discussion about
 the original patch, namely:

  * Does not use an anonymous function.
  * Assumes that WP_MEMORY_LIMIT is in megs.

 The wp_convert_hr_to_bytes() function was not used as it creates a chicken
 and egg scenario due to the wp_initial_constants() function being called
 well before the wp-admin/includes/template.php file can possibly be
 loaded. Restructuring is possible, but this could possibly cause new
 issues while attempting to address this one. So, adding the code directly
 to the check was the route I went with.

 While the patch does assume the WP_MEMORY_LIMIT define to be in megs, it
 makes no such assumption about the existing memory_limit configuration and
 normalizes the size for bytes, kilobytes, megabytes, and gigabytes.

 The patch is added as chrisbliss18-patch.diff.

 Since performance is a concern, I benchmarked the existing code against
 the first patch and my patch. I found that the original patch increased
 processing time 100-120% on my test machines while my patch increased
 processing time by 25-35%. I should note that the processing time for the
 first patch would be higher if I could test it completely (I had to move
 the anonymous function creation to outside the testing loop to prevent
 memory exhaustion, it is not possible to reclaim memory consumed by an
 anonymous function while in execution).

 The benchmark code is attached as chrisbliss18-patch-benchmark.php and
 works as a a good testing platform. The benchmark code uses six different
 test cases. The existing WordPress code has a success rate of 50% while
 both patches have a success rate of 100%.

 Note that my test cases does include "7.5G". I found that while this
 doesn't cause any issues, PHP treats such values as ints by removing the
 decimal, resulting in "7G" for this test case.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/14889#comment:11>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software