Comments

Status:Postponed» Active

blocker is in
i think this issue would be nice for someone that wants to get familiar with composer

Assigned:Unassigned» damiankloip

I think I will check this out today.

Title:Switch the Timer system to use Symfony StopwatchReplace the Timer component with Symfony Stopwatch
Issue summary:View changes
Issue tags:+Proudly Found Elsewhere
Parent issue:» #2173335: Remove deprecated timer_* functions

Might be best to wait for the complete removal of the deprecated procedural functions in #2173335: Remove deprecated timer_* functions (which hopefully lands soon)

But in general, totally +1 → less code to maintain.

There's only one major difference: Stopwatch is not a static class, you need to instantiate an actual object.

You have to retain it in your local scope, and if necessary, you need to pass the object forward to child scopes.

This means that you cannot easily do what we're doing in some places now; e.g., starting a 'page' timer in _drupal_bootstrap_configuration() and consuming that in any other spot of the application.

That is, unless we'd register it as a synchronized service and persist it across container rebuilds, I guess.

But aside from that looks like the API is fairly similar:

Timer::start('event')    Stopwatch::start('event');
Timer::stop('event')     Stopwatch::stop('event');
Timer::read('event')     Stopwatch::lap('event');

One problem is that _drupal_bootstrap_configuration() currently calls the Timer::start('page') right after the classloader got initialized in order to let tools like devel comes in as fast as possible.
I would really wonder whether this needs to be done that early in the bootstrap. Usually you don't use devel to figure out bootstrap performance but do some actual measurements with xhprof.

In the symfony world they replace the http kernel to measure performance at that level.

I can't see any value in breaking APIs (again) for this, really. What is the gain? Is StopWatch in Symfony's list of BC-compatible components? Etc. To me this feels like 9.x material. We shouldn't be looking for APIs to break at this point.

Version:8.x-dev» 9.x-dev

Doing that, unless someone can come up with a compelling reason not to.

Doing that, unless someone can come up with a compelling reason not to.

Symfony uses the stopwatch for various things, so if contrib would use some pieces (like the webdeveloper toolbar), they would have to require both, but sure this is not an important component at all.

AFAICS, we could easily make our Timer piggy-back on Stopwatch like this:

<?php
class Timer {
  public function
start($event) {
    return \
Drupal::stopwatch()->start($event);
  }
?>

Alternatively, make the Timer class a singleton + manually instantiate the Stopwatch service once in a private constructor:

<?php
class Timer {
 
/** Stopwatch instance **/
 
private static $instance;
  private function
__construct() {
   
self::$instance = new Stopwatch();
  }
  public function
start($event) {
    if (!isset(
self::$instance)) {
      new
self();
    }
    return
self::$instance->start($event);
  }
?>

Opened an issue to symfony as Timer::read() does not have a real replacement: https://github.com/symfony/symfony/issues/10175