Expose time spent collecting cycles in `gc_status()`

[sebastianbergmann]

I had a conversation with @Girgias recently about whether it would be possible to retrieve the amount of time spent collecting cycles from userland. He told me that I should probably talk to somebody else.

@edorian told me that the information is available in the Zend Observer API and that it should be almost trivial to make it available to userland.

However, @beberlei tod me that using the Zend Observer API is not required for this. Instead, he proposes to introduce a global variable that counts the time spent in collecting cycles and "just" expose that as part of gc_status()' result.

TL;DR: I would like information on time spent collecting cycles to be part of the array returned by gc_status().

[Girgias]

@arnaud-lb as you’ve touched the GC somewhat recently, what do you think about this and how to go about it?

[arnaud-lb]

Exposing that as part of gc_status() seems to be the way to go. We can measure the time spent in zend_gc_collect_cycles and accumulate to a zend_gc_globals member. We can then expose the total in the result of gc_status().

The CLOCK_THREAD_CPUTIME_ID clock seems to be the most appropriate one for this, as we don't want to count the time spent while the thread/process is not running, e.g. due to scheduling.

Given that in the current algo, finding and freeing garbage are two mostly distinct phases, we could measure them separately. Only the "finding" phase would be what people most commonly call GC overhead.

It could be useful to expose the "mutator time" aka the time spent outside of the GC as well, for reference.

So we could add a few entries to the gc_status() result:

• program_time: Time spent in the program outside of the GC
• collect_time: Time spent in the GC
• scan_time: Time spent finding gargage cycles
• free_time: Time spent freeing garbage, including calling destructors and freeing zvals

[sebastianbergmann]

@arnaud-lb Thank you so much for looking into this! Now, is this something that requires an RFC and a vote or can it "just" be implemented?

[beberlei]

@arnaud-lb I believe counting the wall or monotonic clock time is better here, since that is the only thing user land developers can relate the duration to. I would use CLOCK_MONOTONIC here. Yes, scheduler can interfere - but usually it should not under reasonable load.

Also program_time can easily be calculated based on now and REQUEST_TIME_MS, so i believe only the other 3 have real value.

[arnaud-lb]

@sebastianbergmann it probably does not require an RFC, but we should email internals before merging to ensure there are no disagreements

[sebastianbergmann]

we should email internals before merging to ensure there are no disagreements

Will you do that or should I?

[arnaud-lb]

The email or the implementation? I would be happy to do both, unless you wanted or planned to do it

[sebastianbergmann]

The email or the implementation? I would be happy to do both, unless you wanted or planned to do it

I cannot help with the implementation, unfortunately, and was only volunteering to write the (initial) email to internals. Glad to hear that you'll be doing both. Thank you so much!

[SVGAnimate]

I have some reviews

• I'm working on the Gtk extension which uses a main loop that can run for hours.
  The collection time will surely be large in this case.
  Wouldn't it be better to use zend_date_time instead of zend_time ?

• zend_result zend_startup_time() doesn't seem like an appropriate name to me
  I suggest :

void zend_timer_reset(zend_timer *timer);// elapsed=0
void zend_timer_start(zend_timer *timer); 
void zend_timer_stop(zend_timer *timer);
const zend_date_time* zend_timer_elapsed(zend_timer *timer);