[wp-trac] [WordPress Trac] #18453: Improved doing_it_wrong()

[WordPress Trac]

#18453: Improved doing_it_wrong()
-------------------------+-----------------------------
 Reporter:  azaozz       |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  close        |
-------------------------+-----------------------------

Comment (by chrisbliss18):

 Here's some food for thought regarding performance and memory consumption
 impact due to backtrace parsing as found in my supplied patch.

 I set up a site that had large objects running inside of nested actions
 and function calls, resulting in large backtrace outuput. I then kept
 track of the difference in memory consumption and execution time. The
 backtrace code is slightly modified from my supplied patch as it now can
 show either the source file and line number or class and function name
 (depending on the content of the specific backtrace entry). I'll update my
 patch to reflect this conditional shortly.

 I ran three tests: Shallow, a single backtrace from the top of a theme's
 functions.php file (serialized backtrace size: 967 bytes). Single (Deep),
 a single backtrace from deep inside a large object with a very deep call
 stack (serialized backtrace size: 78,792 bytes). Multiple (Deep), a dozen
 backtraces deep inside call stacks of large objects (serialized backtrace
 size: 158,015 - 162,008 bytes). With these tests, I hoped to derive some
 expectations of the cost of such backtrace detail generation.

 ||Type||Samples||Serialized Backtrace Size||Time Difference||Memory
 Difference||
 ||Control||103||0||0||0||
 ||Shallow||104||967 bytes||+0.0010389 seconds||+20,736 bytes||
 ||Single (Deep)||104||78,793 bytes||+0.0004531 seconds||+388,303 bytes||
 ||Multiple (Deep)||103||158,015 bytes||+0.0186892 seconds||+913,524
 bytes||

 Note that I used "memory_get_peak_usage()" to generate memory usage and
 "microtime( true )" to generate the timings. To keep the testing
 consistent in how it taxed the system, I used ab (Apache Bench) to run 100
 tests (for a good sample size) with a concurrency of 1 (to make sure that
 the concurrency didn't open up some kind of PHP caching technique which
 showed when I upped the concurrency).

 All in all, I think the test went well. The two deep samples aren't
 exactly cheap but they aren't too expensive either as I've seen very
 simple plugins make a bigger performance and memory impact than any of
 these test cases. Of course, since it is possible for there to be
 backtraces in worse scenarios than my samples, I suppose the value is
 purely academic.

 I still would like to see if it is possible to incorporate simple
 backtrace output into the notice as this keeps the information inline with
 the kind offered by PHP's own notices. However, providing information on
 how to gain access to this information is still a positive step forward as
 I just don't like the idea of leaving novice developers in the dark on how
 to find the source of the notice. In other words, I don't want WordPress
 to have any dastardly "Null Pointer Exception" messages as found in Java
 where, if you see the message, you might as well just do something else as
 you aren't likely to find the source of the issue for a while in a large
 project. I would clarify what I mean more, but I'm sure that you'll figure
 it out. ;)

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