Comments on: Flawed Microbenchmarks http://www.procata.com/blog/archives/2005/02/24/flawed-microbenchmarks/ PHP Programming, Web Development, PHP Advocacy and PHP Best Practices. Fri, 10 Sep 2010 12:20:12 -0400 http://wordpress.org/?v=2.8.6 hourly 1 By: Jeff Moore’s Blog » Blog Archive » Microbenchmarks of single and double qouting. http://www.procata.com/blog/archives/2005/02/24/flawed-microbenchmarks/#comment-6021 Jeff Moore’s Blog » Blog Archive » Microbenchmarks of single and double qouting. Tue, 08 Mar 2005 23:23:07 +0000 http://www.procata.com/blog/archives/2005/02/24/microbenchmark-flaws/#comment-6021 [...] Microbenchmarks of single and double qouting. I wrote earlier about flawed microbenchmarks. Today on sitepoint, there was a post on the perf [...] [...] Microbenchmarks of single and double qouting. I wrote earlier about flawed microbenchmarks. Today on sitepoint, there was a post on the perf [...]

]]> By: admin http://www.procata.com/blog/archives/2005/02/24/flawed-microbenchmarks/#comment-5332 admin Fri, 25 Feb 2005 16:33:35 +0000 http://www.procata.com/blog/archives/2005/02/24/microbenchmark-flaws/#comment-5332 Indeed. Good point. One might make the same point about breaking large code bases up into multiple small files. Bad for microbenchmarking, good for flexibility, reuse and modularity. :) Indeed. Good point.

One might make the same point about breaking large code bases up into multiple small files. Bad for microbenchmarking, good for flexibility, reuse and modularity. :)

]]> By: Lukas http://www.procata.com/blog/archives/2005/02/24/flawed-microbenchmarks/#comment-5162 Lukas Thu, 24 Feb 2005 22:00:33 +0000 http://www.procata.com/blog/archives/2005/02/24/microbenchmark-flaws/#comment-5162 Another good example is people measuring the performance overhead of parsing PEAR.php and then mentally multiplying this by the number of PEAR packages that use PEAR.php in their code. Obviously adding infrastructure code in userland is going to incurr overhead, however the point if such code is to make your general life easier. Therefore you are likely to make heavy use of said infrastructure code. This means that the parsing overhead will diminish. Obviously though you would want PEAR.php to have efficient code since its likely that code contained therein is going to be called often. Another good example is people measuring the performance overhead of parsing PEAR.php and then mentally multiplying this by the number of PEAR packages that use PEAR.php in their code. Obviously adding infrastructure code in userland is going to incurr overhead, however the point if such code is to make your general life easier. Therefore you are likely to make heavy use of said infrastructure code. This means that the parsing overhead will diminish. Obviously though you would want PEAR.php to have efficient code since its likely that code contained therein is going to be called often.

]]>