My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
Lagged_Loader  
A replacement for Zend_Loader
performance, optimization, autoload, Zend_Loader, Phase-Implementation, Featured
Updated Feb 4, 2010 by klimp...@gmail.com

Introduction

Lagged_Loader may be used to autoload models, controllers and Zend_ classes. Models and controllers from inside modules are also supported.

So far a couple basic benchmarks showed a 2.5 - 3x performance boost if you switch to autoloading and apply all suggestions from this page.

Details

Installation

Assuming the following path:

/path/to/your/zf/app/library

... executed the following commands:

cd /path/to/your/zf/app/library
svn export http://lagged.googlecode.com/svn/trunk/Lagged ./Lagged

You could also keep track via svn:externals, but I suggest you wait until I "branch off" the code so you're not subject to maybe breaking changes in trunk.

Autoloading

The __autoload() should be setup in your project's bootstrap.

Example #1

function __autoload($className)
{
    static $loader;
    $loader = new Lagged_Loader('/path/to/your/zf/app');
    $loader->loadClass($className);
}

Example #2

define('LAGGED_APPLICATION_DIR', '/path/to/your/zf/app');
function __autoload($className)
{
    Lagged_Loader::loadClass($className);
}

Requirements

For simplicity, the loader expects your Zend Framework code to reside in your projects library/ directory. To gain performance, we are not searching multiple include_path's etc..

As for library code this loader currently supports class code from the Zend_ and Lagged_ namespaces, this is subject to change.

Models and controllers

In order to support model and controller loading (along with those in modules), we expect/suggest the standard project layout:

  • /path/to/project/app/controllers: BarController
  • /path/to/project/app/forms: Form_Login
  • /path/to/project/app/models: Model_Bar
  • /path/to/project/app/modules/foo/controllers: Foo_BarController
  • /path/to/project/app/modules/foo/forms: Foo_Form_Login
  • /path/to/project/app/modules/foo/models: Foo_Model_Bar
  • /path/to/project/app/library

To utilize the loader, replace the Zend_Loader in the framework code:

grep -rl require_once . | grep -v svn \
    | xargs perl -pi~ -e 's/Zend_Loader::loadClass/Lagged_Loader::load'

Lagged_Loader::load() imitates the behaviour of Zend_Loader::loadClass().

To make Lagged_Loader play nice with the regular Zend Framework code base, you need to define the following constant (which saves us more "lookups" and creates absolute paths) for include in your project's bootstrap:

// no trailing slash
define('LAGGED_APPLICATION_DIR', '/path/to/project');

Notes on development

  • Lagged_Loader will expect all files to be in place
  • Lagged_Loader will not validate the files to load
  • because include raises a warning, I suggest you enable display_errors
  • for production the error_log is recommended, and display_errors should be off

Further optimizations

To optimize further, I also suggest you strip require_once from all framework code in order to gain performance:

grep -rl require_once . | grep -v svn |grep -v Loader \
    | xargs perl -pi~ -e 's/require_once/#require_once/'

Where do we go from here?

My current todo list includes:

  • support extending of the library namespaces (to support code outside of Zend_ and Lagged_)
  • add setters for the standard paths, so you can make them fit your gusto
  • more benchmarks (more details, etc.)
  • more documentation
  • maybe more test cases
  • branch off trunk
  • PEAR packages

What I won't be doing:

  • support any more obscure file-class-convention (except for what I currently support)
  • add too much configuration, because this makes things slower
  • add extended checks for the environment -- Lagged_Loader is not too suitable for development


Sign in to add a comment
Powered by Google Project Hosting