Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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:
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.
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:
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);
}
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.
Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.
Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)
Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)
Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)
Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)
Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.
Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.
Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.
Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.
Comments
Comment #1
RobLoach#1935970: Convert timer_* to a utility class and convert tests to phpunit
Comment #2
ParisLiakos CreditAttribution: ParisLiakos commentedblocker is in
i think this issue would be nice for someone that wants to get familiar with composer
Comment #3
damiankloip CreditAttribution: damiankloip commentedI think I will check this out today.
Comment #4
sunMight 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:
Comment #5
dawehnerOne 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.
Comment #6
webchickI 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.
Comment #7
webchickDoing that, unless someone can come up with a compelling reason not to.
Comment #8
dawehnerSymfony 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.
Comment #9
sunAFAICS, we could easily make our Timer piggy-back on Stopwatch like this:
Alternatively, make the Timer class a singleton + manually instantiate the Stopwatch service once in a private constructor:
Comment #10
dawehnerOpened an issue to symfony as Timer::read() does not have a real replacement: https://github.com/symfony/symfony/issues/10175
Comment #11
catchIf 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.
Comment #12
dawehner@catch
We really don't talk about a lot, tbh.