Comments

RobLoach’s picture

ParisLiakos’s picture

Status:Postponed» Active

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

damiankloip’s picture

Assigned:Unassigned» damiankloip

I think I will check this out today.

sun’s picture

Title:Switch the Timer system to use Symfony Stopwatch» Replace 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');
dawehner’s picture

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.

webchick’s picture

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.

webchick’s picture

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

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

dawehner’s picture

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.

sun’s picture

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

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:

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);
  }
dawehner’s picture

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

catch’s picture

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

If this is worth doing (not sure it's worth it, how much code do we actually save?) we can add it without breaking BC, moving back to 8.x.

dawehner’s picture

Version:8.0.x-dev» 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.