You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
...
* @param string $token token for the code block
* @param string $category the category of this log message
* @see endProfile()
*/
public staticfunction 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:
later you'll have to seek for log records corresponding to this profiling record to retrieve this info;
its additional overhead which will affect profile timing
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;
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
The text was updated successfully, but these errors were encountered:
As of now:
The same is for
endProfile
.Here
$token
is just a key to match the correspondingbeginProfile
andendProfile
records.But for logger
$token
is message, which can beWhen 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:Could be useful if
beginProfile
andendProfile
could accept the same format aslog()
(finally - they are just proxy functions forlog()
).Formally passing array to
beginProfile
andendProfile
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 byVarDumper::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 byVarDumper::export
The text was updated successfully, but these errors were encountered: