Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profiling could be more informative #7617

Closed
SDKiller opened this issue Mar 7, 2015 · 2 comments
Closed

Profiling could be more informative #7617

SDKiller opened this issue Mar 7, 2015 · 2 comments

Comments

@SDKiller
Copy link
Contributor

SDKiller commented Mar 7, 2015

As of now:

   ...
     * @param string $token token for the code block
     * @param string $category the category of this log message
     * @see endProfile()
     */
    public static function beginProfile($token, $category = 'application')
    {
        static::getLogger()->log($token, Logger::LEVEL_PROFILE_BEGIN, $category);
    }

The same is for endProfile.
Here $token is just a key to match the corresponding beginProfile and endProfile records.

But for logger $token is message, which can be

 * @param string|array $message the message to be logged. This can be a simple string or a more
 * complex data structure that will be handled by a [[Target|log target]].

When profiling you could wish (and usually it is nesessary) to save additional information related to it - for example object state (often - both for begin and end of profiling).

Of course you can immediately log this info as separate record using log(), but:

  1. later you'll have to seek for log records corresponding to this profiling record to retrieve this info;
  2. its additional overhead which will affect profile timing
  3. object which properties you want to pass as additional info may change between profile and log records, so you need to introduce additional variables to save it state at the moment of profiling to be sure that proper values will be logged;
  4. its additional code.

Could be useful if beginProfile and endProfile could accept the same format as log() (finally - they are just proxy functions for log()).

Formally passing array to beginProfile and endProfile is possible, but is actually restricted by \yii\log\Logger::calculateTimings - as it treats $token only as string for comparison.

For logging there is no problem as \yii\log\Target::formatMessage processes non-string messages by VarDumper::export

IMO - \yii\log\Logger::calculateTimings could be modified.

If $token was passed as string - left as is.
If as array - their could be a constant, a naming convention or configuration parameter for token array key, and the rest of the message could be processed by VarDumper::export

@SDKiller
Copy link
Contributor Author

SDKiller commented Mar 7, 2015

Something like this:

...
    public $tokenKey = 'token';

...
    public function calculateTimings($messages)
    {
...
        foreach ($messages as $i => $log) {
            list($message, $level, $category, $timestamp, $traces) = $log;
            $token = $this->resolveToken($message);
            if ($token === null) {
                continue;
            }
...
            } elseif ($level == Logger::LEVEL_PROFILE_END) {
                if (($last = array_pop($stack)) !== null) {
                    $lastToken = $this->resolveToken($last[0]);
                    if ($lastToken === $token) {
...
    }

    /**
     * @param array|string $message
     * @return string|null
     */
    protected function resolveToken($message)
    {
        $token = is_string($message) ? $message : ArrayHelper::getValue($message, $this->tokenKey, null);

        return $token;
    }

UPD: updated example

@yii-bot
Copy link

yii-bot commented Jan 24, 2016

Issue moved to yiisoft/yii2-debug#81

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants