Profiler initialization, setup, and the _profiler microapp

Initialization

Initialization is performed in the script ~/application/Init/Profiler.php as follows: require SysConf_Path::getLibrary() . 'Jet/Debug/Profiler.php';

if( SysConf_Jet_Debug::getProfilerEnabled() ) {
    $profiler_controller_path = SysConf_Path::getBase() . '_profiler/Controller.php';
    if(file_exists($profiler_controller_path)) {
        require $profiler_controller_path;
    }
}

Please note:

• You must use the classic require and not rely on Autoloader. It is not yet active when the profiler is initialized. In fact, the profiler is actually the very first thing to be initialized and activated right after the basic settings (especially the directory paths).
• To load Profiler, all you need is one require, which already loads everything you need - so you just need this short piece of code.
• You can see that when Profiler is turned on, it loads the microapplication _profiler. It's one of the micro-apps (the other is _installer and the tools in the _tools directory, namely Jet Studio) that are part of the PHP Jet package. And which you can of course customize according to your needs. We'll talk more about it later.

Settings

To enable and disable the profiler, there are methods SysConf_Jet_Debug::setProfilerEnabled( bool ) and SysConf_Jet_Debug::getProfilerEnabled(). In practice, it is turned off/on (in terms of configuration) in the Jet platform settings, i.e. in the ~/application/config/Jet.php scripts.

You can make further settings and especially major changes by editing the _profiler microapplication.

Microapplication _profiler

I wrote about Profiler as integrated. In fact, this is only partially true.

Integrated into PHP Jet is the part of the profiler that handles application runtime tracking and information gathering. This is really integrated, it's part of the Jet library itself and other platform components as well as applications call this part of Jet in order to gather the necessary runtime information.

What is not integrated (and therefore destined to be fully customized to your needs) is what the profiler output displays, i.e., that status bar at the bottom of the page, the overall runtime information output, and the call graph (the call graph is the output of XHProf - not the Jet profiler).

This is all separated and can be found in the ~/_profiler directory.

There is certainly no point in describing this microapplication in full detail. It's only a few hundred lines of code, and it's best to take a peek. But at least information about its structure is good to get an idea:

• ~/_profiler/Controller.php - this is the controller of the whole microapplication. This is where the actual turning on and setting of the Profiler is done and the overall behavior of the microapplication is decided.
• ~/_profiler/views/*.phtml - view scripts.
• We have Controller, we have View, but where is Model? The Model is the Profiler itself and, more importantly, the information captured by it. The run information is represented by the Jet\Debug_Profiler_Run class and its associated classes. This is the model that the microapplication works with.

Important Note: The name of the microapplication directory starts with the _ character. Recall that it should not be present on the production environment at all, and if it is, it should only be present temporarily, but never permanently. This microapplication is intended primarily for your localhosts and development servers.