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:

<?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);
  }
?>
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