[Solar-talk] Namespacing with concrete class functionality

[Travis Swicegood]

Rodrigo Moraes wrote:
> On 11/8/06, Travis Swicegood wrote:
>   
>>  These are all with a namespaces array of
>> Solar, Domain51.
>>
>> Using the simplest form - loading a single class, it looks like there's
>> a 5% hit in performance.  Using the bookmarks app, it looks like there
>> was a 13% hit.  This just proves foreach() hurts anyway you shake it.
>> I'm try some tweaks and see if I can get it better performance out of
>> this.  If I can keep both under 5%, I'd be happy.
>>     
>
> 5% would not be bad. The real damage seems to happen when your primary
> namespace doesn't have most of the classes that will be needed in a
> real app. Then Solar will try to find many of the classes more than
> once. Since adding precedence to a Vendor is one of the main reasons
> to have namespaces, I think you should benchmark it using ('Domain51',
> 'Solar') for the namespaces array.

You're correct.  I ran some numbers running array_reverse() at load time 
the way Solar_Controller_Front does and reversing them in the config.  
There's a 6.66% decrease running array_reverse every time, so you'd want 
to do that in the config.

The results of the reversed array (via config) is roughly 20% slower 
than if Solar is first.  That's with a full include_path.  I can pick up 
33% of that loss by trimming my include_path to only include my 
namespace and Solar in the include path.  Of course, I'd have the same 
increase if I trimmed the include_path non-namespaced code too.

One thing I haven't tried yet is replacing all of the Solar specific 
loadClass() class with loadClass("Solar_Some_Class", true) so they're 
all concrete.  Assuming I'm correct, the $concrete parameter should add 
fractions of a percent to the execution time.  That would be the ideal 
situation, in my opinion.  Make Solar the flex point, and as you build 
your application, you make it concrete as speed becomes necessary.

Another thing that's come to mind would be a memcache'd array for 
loadClass() that stores known locations of requested classes.  This is 
would be nice regardless of namespaces or not.  Of course, not everyone 
has access to memcache, so it would have to be made optional.  
Refactoring loadClass() so it's the interface into a Solar_Class_Locator 
object would allow you to configure what type of locator you use.  Drop 
in a Solar_Class_Locator_Memcache and it could cache an array of known 
classes and their locations - that removes the entire finding process 
which is the expensive part of this equation.

-Travis