RE: [PECL-DEV] PECL account for publishing an extension

Hi all, Johannes, This is a new try to send the reply to the mailing lists. Tried again a few weeks ago, the message just disappeared. During this time we manage to publish the V2 and update documentation, still at http://www.exteon.ro/en/products/php-tools/web3tracer > 1) Can you describe the difference over xhprof? Why do we need a fork instead of taking it over and improving it? This might ensure most users get the best experience y not having to select between competing choices ... I will start with a little background: the main concern, when we started the fork, was properly dealing with recursion. Here are 2 call graphs produced by XHProf and web3tracer for the same script to explain what we mean by "properly": http://www.exteon.ro/web3tracer/xhprof.jpg http://www.exteon.ro/web3tracer/web3tracer.jpg Our other concern was having lowest per-call overhead possible. Recursion is an unavoidable reality in OOP (in the form of recursive getters for instance) or in MVC framework s (where view templates are usually expanded in a recursive cycle). Overhead is a concern manly in OOP setters and getters, which get a huge number of calls but are very lightweight (eg. return $this->prop). I found XHProf a good starting base. However, XHProf is designed (out of different but nonetheless valid concerns, I'm sure), for small memory footprint. Therefore every call is fully processed and aggregated on each call. When we added the recursion processing on this model, the overhead became unreasonable. Instead, we decided to do it differently: just store the call tree in a simple stack structure on every call and do the whole post-processing on trace end. We allocate more memory, that is also mlocked (if available) for performance and just store the raw data during the run.This means better performance, accurate recursion processing, albeit with a larger memory footprint. The PHP equivalent of the recursion logic can be seen here (a much easier read than C code): http://www.exteon.ro/en/products/php-tools/xt2callgrind/ This also means we actually replaced the whole business login in XHProf, leaving only the meta (Zend declarations, hooks etc) and timing functions. It's a different design that we cannot achieve by incrementally building on top of XHProf, except maybe building a 2-headed dragon (something like, a xhprof-mode switch that goes back to the old xhprof codebase). I'm not sure how we would maintain the two-headed beast or even if it's an idea to discuss, seems awkward to me. However, V2 does produce XHProf-compatible output out of the box, with the exception that we don't implement the sampling mode in XHProf, as we have yet to find some use for it in our projects. Also we implement a different memory delta logic to prevent the XHProf negative totals and >100% deltas. With some leeway, some may consider it an "improved" XHProf. However, since the design is different, I don't see it as an incremental transition from XHProf; rather it would make more sense that the 2 coexist and let the community make the transition, if it proves to be indeed an improvement. I would also not call web3tracer "stable" at this point; it is stable for us, but it could benefit by more testing from the users. When I composed the previous mail, I was about to call XHProf "unmaintained", but since then I see a new version was pushed. So I could also not impose on "taking it over". I would highly value any feedback from XHProf maintainer Bill Fumerola (kudos!) on the matter. > 2) We prefer BSD/Apache/MIT-style licenses. Keeping similar licenses means we can collaborate in the PHP space. You have chosen LGPL which essentially means you can profit from developments in other extensions (i.e. take code from xhprof or xdebug) while those can't benefit from your work. I understand the interest of keeping the code open but from my years in this community I see more trouble from companies keeping there improvements in house (where [L]GPL won't help) than from commercializing by third parties. (what [L}GPL essentially prevents) We have no strong feelings in this matter, we released the V2 under the initial XHPof Apache license. Thanks, Dinu