Aug 17, 2010
My application uses a 'central' page controller that grabs a bunch of files (I hesitate to say libraries) each containing a few related classes, using require_once, before fetching the request. As in:
View 3 Replies
require_once (dir_lib . 'db.php');
require_once (dir_lib . 'uuid.php');
require_once (dir_lib . 'data.php');
require_once (dir_lib . 'token.php');
require_once (dir_lib . 'logs.php');
require_once (dir_lib . 'time.php');
I haven't bothered to check memory usage until recently installing the (awesome, but gigantic) 'HTML Purifier' library and glancing at its autoloader. Apparently, autoloader on not, each script instance now weighs in at a whopping (sweet jesus!) 5376 kilobytes memory usage. (I have no idea what the built-in autoloader is for if that's the end result, but I digress) Without the HTML Purifier, most instances still weight in at over a megabyte.
Reading about the PHP autoload functions I'm getting the impression that the autoloader is meant strictly for OOP. With the exception of the purifier library, I'm using very little object-oriented code. Am I just misunderstanding the concept? Is there any other practical way to avoid blindly loading a bunch of classes that may not be needed for each request? Am I just being lazy for trying to include them all up-front?
Repeating this comment up up here to clarify what I meant by non-oo, if that makes much difference:
I am basically using classes in lieu of namespaces without using (hardly) any actual OOP. That is to say, the "DBFunctions" class may contain, for example, the functions "execute" and "getRow". The functions are invoked with a static method call such as "dbFunctions::execute($sql)."