Re: PECL account for publishing an extension

On Mon, Jun 3, 2013 at 5:53 PM, Johannes Schlüter <johannes@php.net> wrote: > On Fri, 2013-05-31 at 15:35 +0300, Constantin-Emil MARINA wrote: > > About one year ago we forked off XHProf profiler (or rather, kept > meta-code > > and timing functions, rewrote the rest, so this is NOT a maintenance > build) > > to provide recursion handling and better performance and KCachegrind > output. > > The v1 version can be found here: > [...] > > We would like to publish this extension on PECL to gain visibility and > > community feedback. There are a number of performance monitoring tools > that > > could benefit from the recursion handling rewrite. I wuld ask you to > review > > the opportunity of this and if so grant an account on PECL. > > There are two things which concern me: > > 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 ... > > 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) > > > I would also like to ask a question (maybe this is not the right place, > but > > it's a good starting point): for the profiler, it would be very useful > to be > > This is the right place, while typically it is better to have separate > threads for different topics) > > > able to hook into the zend engine memory handling functions, especially: > > > > - emalloc, efree etc. for timing and quantization of memory > > requests; the peak and current memory usage are not great indicators for > > memory performance > > I think the only way to do this without evil rewrite of in-memory-code > would be to ask users to run with USE_ZEND_ALLOC=0 in their environment > and overwrite AG(mm_heap).[_malloc|_free|_realloc] (see struct > _zend_mm_heap), I'm not sure how easily this can be done without > startup/shutdown order issues ... > > > - the GC sweep for timing the GC operation > > I don't have a proper way for this at hand, I'm not aware of any hooking > points there and there are quite a few places where the compiler might > be inclined to inline things making binary patching really nasty. > > > Note: This message was sent before and man-handled by the list bot > (required > > confirmation), but still doesn't appear on the mailing list, and no reply > > received. Sorry if this message is in duplicate. If someone sees this, > > please reply directly to from address, we can't confirm the email is > going > > where it's supposed to. > > Now it worked ;) > > > Thanks, waiting to hear from you, if you're in the neighborhood drop a > SYN, > > Some time ago I was at Cluj and Brasov not Bucharest :-) > > johannes > > > > -- > PECL development discussion Mailing List (http://pecl.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > Hi, I love you guys for adding support for Cachegrind output! -- Ferenc Kovács @Tyr43l - http://tyrael.hu