In which plugins is the Timer API used? From the sound it doesn't seem like needed as an API?

@tsteur FYI you can see the inspection output here http://builds-artifacts.piwik.org/protected/inspections.all/2015-04-04/inspections/all_inspections.out - it's used in VisitorGenerator

Maybe same applies here as in #7790 (comment)

If possible, I would like to avoid making this a public API (to keep the list of available APIs "short") but if needed I'm ok with it.

The idea is that this isn't a Piwik API, it's a component. Like the Symfony Stopwatch has nothing to do with the framework, the Timer has nothing to do with Piwik. I've considered replacing it with the Stopwatch component but it wasn't worth it because we use things that aren't available, and the Stopwatch is more complex. I have also searched packagist and considered all other alternatives, but not worth it imo.

That's why I moved it in another namespace: later we can move it into a separate repo. Hope that clears things up.

It doesn't really make a difference for me whether it is a component or not... What I meant is marking it as @api which means we have to support it and it will appear on developer.piwik.org. I'm afraid we're about to mark too many classes as API (component or not) that are not really needed just because they were used in some internal plugins.

@tsteur @mnapoli How would you feel about adding an @api method to ConsoleCommand like this:

protected function performTimedOperation($successMessage, $callback)

? The method would use Timer internally, and print out the success message w/ the elapsed time. This way, we provide an easy way for commands to spit out the time (which seems a common need for long running commands) w/o exposing the Timer class.

I'm not sure, it probably depends on the use case.

If someone wants to know the time the command took, one could simply use the Linux command time eg time ./console. Something like this is usually good practice and we should not really reimplement native system features. We could otherwise, if time is not acceptable, maybe rather add an option that is available to all commands and will print the time instead of having that new method. This way it would be available to all commands without having to do anything.

If we want to print it always after command execution for specific commands then such a method could be helpful. Although I'm not sure if I'd prefer to use Timer directly then as we'd otherwise end up adding such methods everywhere (but I reckon it would maybe not happen in this case as we usually don't have long running jobs elsewhere). Do we have an issue where a user / developer asks for seeing the time the command took? If not, I would probably not add it. If yes, I'd be ok with it but don't feel really good about it. Also I'm not a fan of callbacks. I'd try to solve it differently. Eg always save the start time before executing and afterwards, if performTimedOperation is called, calculate the difference.

If someone wants to know the time the command took, one could simply use the Linux command time eg time ./console.

This doesn't help if you're timing individual steps, such as optimizing multiple tables (which allows users to see progress + get an idea of how long the next step will take).

Eg always save the start time before executing and afterwards, if performTimedOperation is called, calculate the difference.

I have no idea what you mean by this, but how would it be easier than using a callback?

This doesn't help if you're timing individual steps, such as optimizing multiple tables (which allows users to see progress + get an idea of how long the next step will take).

That's why I asked for the use case. I don't see this in the Command class. I'd actually rather make the Timer API public if it is actually needed in a third party plugin (if needed in core plugin then we don't have to expose it). Even better would be maybe to develop (probably such a helper already exists somewhere) a Symfony Console helper but I think it would be hard to document/expose.

I have no idea what you mean by this, but how would it be easier than using a callback?

I don't see a need for a callback here. It makes it rather more complicated to understand, to debug and profile etc. It would be easier to not have a callback since you'd simply write a command as usual:

protected function execute(InputInterface $input, OutputInterface $output)
{
    Filesystem::deleteAllCacheOnUpdate();

    $this->printTimingInformation($output);
}

As you want to time different operations as you just said this would not help you there.

I would personally either use the Timer class directly or add a helper for Symfony Console as the use case seems to me to specific for adding it to Command directly

A helper could be exposed via @api if the helper type has to be referenced by code that uses it. I don't know if there are existing add-ons for this. Honestly, it seems too small a use case to bother with another library.

I'd rather remove usage of such timer class to replace it with manually using microtime() instead of adding unnecessary complexity. A stopwatch component is very basic and generic need, if we don't want to provide a very simple and basic component like this I don't think it's a good idea to expose and maintain a very restricted helper that applies only to a very specific use case (we'll later be adding the same thing for web, and then for logging, etc etc.).