[Solar-talk] Performance ideas

[Paul M Jones]

On Oct 16, 2007, at 12:52 PM, Richard Thomas wrote:

> As a longtime savant fan figured it was about time I show up here...

Hey Cyberlot, it's good to have you on the list.  :-)


> 1. File loading, this is the great thing about ZF.. Zend sees these
> issues and are working with the php developers to resolve some of
> these.. There are some stat patches on the way that will help
> loading.. That being said ZF now loads 10 files just to load the
> controller code before any controller or action has been called..
> ugg..

I think Solar needs about 18 files total for "hello world" ... might  
be a bit fewer at this point, but that covers the bootstrap, front,  
page, locale, view, URI, and 3 helpers iirc.  Having said that, once  
they're in an opcode cache like APC, I think the performance hit is  
negligible.  (That applies to Zend as well.)


> 2. Debugging code... Half the job of a framework is to make it easy to
> program in, this means there tends to be a lot of "extra" debugging
> code to produce useful error messages and such.. Great but nice if it
> could be disabled in production
...
> 1. Ability to turn off debugging code/debugging levels

My intuition is that you would need a check each time to see if  
specific debug code should execute, so conditionally turning off  
debug code might have a perverse effect.  ;-)


> 2. Path hints.. Ability to tell the system any class that starts with
> X is in directory Y so absolute paths can always be used. This would
> allow a single absolute path to /home/you.com/library but also allow
> you to load /usr/local/php/pear/Mail.php without problem using
> absolute paths.. Granted a well thought out structure can reduce this
> issue greatly but when dealing with third party libraries it can be
> very useful

That sounds interesting -- it might be possible to have a Solar  
config key that says "here's the base directory for all Solar etc.  
classes".  IIRC, Clay Loveless had this idea as well last year, but  
there was some reason back then that I didn't want to do it.  Don't  
recall now what that reason was.


> 3. Simple routing (At this point I have only used Solar in
> benchmarking so this might be off base). ZF's controller is extremely
> powerful but provides no easy way to bypass all the fluff and get
> simplistic routing out of it without a ton of overhead. A well thought
> out project doesn't need very complicated routing
> http://www.test.com/aboutus for example doesn't need its own
> controller its a simple about us page why not load from the index
> controller IE Simple Routing for simple pages.

Solar_Controller_Front and _Page are dead stupid simple in the  
default cases.  URI's are assumed always to be "controller/action/ 
param".  Thus, for "foo/bar/baz", the Solar front-controller invokes  
Solar_App_Foo::actionBar($baz).  Static routes in the front  
controller allow you to map a controller name directly to a class, so  
"foo" can map to Solar_App_OtherFoo instead.  No regex engine at all.

Note that the front controller and page controller are almost  
completely decoupled from each other.  Rodrigo Moraes has developer a  
ZF-like regular-expression router that is a drop-in replacement for  
Solar_Controller_Front, so you have pick which of the best worlds you  
want to live in.

Hope this helps answer your questions (such as they were) ... please  
let me know if it does not.



--

Paul M. Jones  <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5.  <http://solarphp.com>

Join the Solar community wiki!  <http://solarphp.org>

Savant: The simple, elegant, and powerful solution for
templates in PHP.  <http://phpsavant.com>