ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life
back 1  2  »  

Remember: be nice to byte code caches

Autoload is kinda convenient. Especially since in PEAR we have such a clear mapping of class name to file name. I do not really understand why some libraries and projects have these insane class name to file name mappings like ez Components and I think symfony also has them. Anyways while it seems kind of nice one must be weary of the idea that they speed up your code. If you are running a byte code cache (which anyone who cares about performance of course does) you will get quite the opposite. Here is Rasmus's answer on this taken straight from #php.pecl:

<arnaud_> does autoload have a performance impact when using apc ?
<Rasmus_> it is slow both with and without apc
<Rasmus_> but yes, moreso with apc because anything that is autoloaded is pushed down into the executor
<Rasmus_> so nothing can be cached
<Rasmus_> the script itself is cached of course, but no functions or classes
<Rasmus_> Well, there is no way around that
<Rasmus_> autoload is runtime dependent
<Rasmus_> we have no idea if any autoloaded class should be loaded until the script is executed
<Rasmus_> top-level clean deps would speed things up a lot
<Rasmus_> it's not just autoload
<Rasmus_> it is any sort of class or function declaration that depends on some runtime context
<Rasmus_> if(cond) function foo...
<Rasmus_> if(cond) include file
<Rasmus_> where file has functions and classes 
<Rasmus_> or heaven forbid: function foo() { class bar { } }

As a result its very important that libraries are designed in such a way that users that care about performance can optionally explicitly include all files instead of relying on autoload. As Rasmus points out conditional includes are also not a good idea, but I rarely see them as sensible or even required anyways. Most of the time they may only seem sensible when you ask the wrong questions. From the top of my head I can only think of a BC lib for shrink wrapped products as a place to use conditional function/class definitions.

Comments



Re: Remember: be nice to byte code caches

Hmmmm. But without autoload, things can get messy as they are no package support in PHP. Loading everything is not a good solution, when you only need a bunch of classes in your framework at a given time...

If you don't have an opcode cache, loading everything result in very bad performances. When you design a framework that will run on different environments, you better use autoload I think.

Re: Remember: be nice to byte code caches

Seems like rasmus things very much from his C-background where you need to know exactly what you are going to include before you compile..

Makes total sense in that world.. however, lots of us use 1 entrypoint in the application (index.php) and it's simply not feasible to pre-load every class you might need..

Some of my classes are even loaded based on a java-web.xml-like url-to-class mapping file.. I try to be good and load every class before I use everything in the deeper levels of the application.. but in some stages this simply not works well..

Still seems weird that the classes can't be cached.. Even though my include is conditional, after require_once kicks in, it would seem that the PHP parser needs to kick in to parse the new file.. which will generate opcodes..

makes me wonder about the quality of the php engine

Re: Remember: be nice to byte code caches

Oops.. typo in there.. oh well I guess people get my point

Re: Remember: be nice to byte code caches

Hello,

Could you get the best of both worlds like this:


index.php:
<?php

do_page_using_my_framework();
exit;

// will APC be tricked into caching these even though they are never executed?
include 'framework/a.php';
include 'framework/b.php';
include 'framework/c.php';
?>

Re: Remember: be nice to byte code caches

Yes, I personally love front controllers too, but the point of my post was to make it clear that anyone who designs libraries should make sure that the user has a decent chance at figuring out what files to include explicitly so that if they do not use a front controller but do use a byte code cache, that they can get maximum performance.

Re: Remember: be nice to byte code caches

It would be nice to have a document on "Best practices with APC" ... or maybe that could be the topic of a conf talk.

Re: Remember: be nice to byte code caches

Looking at my own code.. I see that very first thing thats happening is the loading of the dynamic front controller..

This means everything happening after that is conditional and therefore not picked up by APC..

oh well

Re: Remember: be nice to byte code caches

Oh this news is awesome. Is this only an APC issue or is this a general problem of byte code caches?

And yes, I never understood why other libraries or projects do not use the PEAR style of class/file naming Thus an autoload implementation wouldn't need to be much longer than 3 lines...

To come back to your 'question', I think a good autoload implementation could record what files are used on a request X (e.g. module/action combination) and should generate an 'include file' that includes all required files for the request.

One could use get_included_files() / get_required_files() at the end of a request to build such an include file!?

Re: Remember: be nice to byte code caches

Ok.. maybe not a good idea if it leads to a conditional include... :-(

Before you can post a comment please solve the following captcha.
your name


1  2  »