Re: XML_RPC2 and class profileration, or the myth of require_once performance penalty

I'm going to quote Greg here, adding his other issues with lots of classes:

You require people wishing to process values sent and returned from XML_RPC to create a huge number of objects. This will substantially increase memory usage, which is another unnecessary inefficiency.

Your XML_RPC2_Value_* is totally unnecessary, and does not make it simpler to use the class, or easier to debug (try var_dump()ing such a monster as opposed to a PHP array)

So that leaves us with 2 big concerns, usability/debugability and memory usage. On a heavily loaded server like pear.php.net memory usage becomes a much bigger factor then execution time. Also giving require_once times on linux isn't always correct since the system calls seem to be much faster then other unixes, (past experience has proven require_once to be an order of magnitude slower on solaris). I'm also guessing that the require_once time can also be affected greatly by system load, amount of memory available for disk caching and the amount of disk actvivity. -josh Sergio Carvalho wrote:

Hi all, During the discussion around my XML_RPC2 proposal, the ever present dogma of decreasing performance against the number of files used was raised again. This is, for me, a blatant case of early optimization, prevalent among PHP developers, so I thought it would be useful to take the chance and use XML_RPC2 to prove the falsity of the dogma. The popular mantra goes somewhere along these lines: - "Benchmarking shows that the most expensive operation in PHP is require_once, even with a stat cache." - "Multiple classes incur heavy performance losses, as it is necessary to compile the class in every request". So, I thought I could get XML_RPC2 which, according to Greg is heavily misdesigned in the XML_RPC_Value subtree, and put it through a profiler. The benchmark was done using the already existing unit test, which makes an echo request against a local (python) xml-rpc server. The results are here: 1. http://files.sergiocarvalho.com/2005/xml_rpc2/kcg_1.png 2. http://files.sergiocarvalho.com/2005/xml_rpc2/kcg_2.png 3. http://files.sergiocarvalho.com/2005/xml_rpc2/kcg_3.png 4. http://files.sergiocarvalho.com/2005/xml_rpc2/kcg_4.png 5. http://files.sergiocarvalho.com/2005/xml_rpc2/cachegrind.out.3356823835 The most interesting images are (2) and (4). (2) shows execution time as coloured rectange areas, with times in percentage of total. Conclusions from observing (2): - 55% of time is spent executing the call, 28% setting up XML_RPC2, 5% parsing the client code (the rest in the test script itself). - The several require_once's needed for XML_RPC_Value instances, account for 5% of request time. Image (4) shows the call tree, with time in 10^-7 second units. From (4), we can further observe that total request execution time was 14ms. From these, I'd like to call to attention that the HTTP transaction cost 5ms. For real world scenarios, with remote HTTP, this number would be be closer to 200ms, making *everything* else account for (9/200) = 4.5%. As requiring once and parsing accounts for 5% of this value, when discussing performance related to require_onces, we are discussing 0.005% of total execution time. In my experience, reducing the number of files is here often used as an excuse for affecting package design. *Do not do this* without going through a profiler first. For most cases, there will be something (DB, image processing, network communication) that will overshadow any performance penalties you pay with require_once, which isn't that big anymore. I'd like to hear your experiences. Let's try to debunk this myth once and for all. Cheers, Sérgio Carvalho