Re: PECL account for publishing an extension

On Sat, Jun 22, 2013 at 3:42 PM, Constantin-Emil MARINA < dinu.marina@exteon.ro> wrote: > 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 > > > -- > PECL development discussion Mailing List (http://pecl.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > Hi Johannes, Are your concerns resolved with the last reply (and with the release of V2)? I think this would be a great addition to pecl. -- Ferenc Kovács @Tyr43l - http://tyrael.hu