Re: PECL account for publishing an extension

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