Re: XML_RPC2 and class profileration, or the myth of require_once performance penalty
| From: | Joshua Eichorn | Date: | Thu, 12 May 2005 17:44:11 +0000 |
| Subject: | Re: XML_RPC2 and class profileration, or the myth of require_once performance penalty | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-37594@lists.php.net to get a copy of this message | ||
For me the concern isn't as much about speed as its about usability. You have more public classes then ext/Soap has public methods and if anything Soap is more complex then xmlrpc.
That in itself shoudl lead us to question the design. PHP is not Java and any design that looks like its a direct java port is going to recieve from flack (rightly or not).
-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