https://github.com/symfony/Stopwatch

Comments

robloach’s picture

robloach
he/him
commented
Status: Active » Postponed

#1935970: Convert timer_* to a utility class and convert tests to phpunit

ParisLiakos’s picture

ParisLiakos commented
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

damiankloip commented
Assigned: Unassigned » damiankloip

I think I will check this out today.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
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

dawehner
Primary language German
commented

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

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

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

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Version: 8.x-dev » 9.x-dev

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

dawehner’s picture

dawehner
Primary language German
commented

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

sun
Primary language German
Location Karlsruhe
commented

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

dawehner
Primary language German
commented

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

catch’s picture

catch
he/him
Primary language English
commented
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

dawehner
Primary language German
commented

@catch
We really don't talk about a lot, tbh.

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.

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

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.

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

Version: 8.2.x-dev » 8.3.x-dev

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.)

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

Version: 8.3.x-dev » 8.4.x-dev

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.)

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

Version: 8.4.x-dev » 8.5.x-dev

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.)

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

Version: 8.5.x-dev » 8.6.x-dev

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.)

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

Version: 8.6.x-dev » 8.8.x-dev

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.

Version: 8.8.x-dev » 8.9.x-dev

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.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.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.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

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.

Version: 9.4.x-dev » 9.5.x-dev

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.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

smustgrave commented
Status: Postponed (maintainer needs more info) » Closed (outdated)

Since there's been no follow up to above in 3+ months going to close out. If still a valid task please re-open

Thanks all!