[Solar-talk] Performance ideas

Tue Oct 16 15:50:45 CDT 2007

I agree about the excessive use file_exists/class_exists when it comes
to loading classes.  The fact that every path in the include path is
scanned makes it a little worse, and then multiply that when used in
conjunction with the file and class stacks. I mentioned a while back
that caching the absolute paths might be a good idea for production
environments, but its hard to wiggle that in on your own because there
are dependencies inside the arch class, and the usage of the stack
classes by the core api is pretty tightly woven in as well.

On 10/16/07, Richard Thomas <lists at cyberlot.net> wrote:
> 1. Again calling from my exp looking at ZF and assuming you do some of
> the same things there are a ton of class_exists, file_exists and other
> checks that in production are not really usefull at all. The question
> then becomes is "if(DEBUG & class_exists)" when debug = 0 faster then
> "if(class_exists)".. Leads to a lot of nitpicking but I am just anal
> like that sometimes
>
>
> 2. It would have to be transparent.. If not defined it should still
> work, matter fact if someone didn't define hints it would skip them so
> it shouldn't affect peformance and more then a single boolean if
> statement.
>
> 3. Sounds great, need to dig a little deeper into that.
>
>
> On 10/16/07, Paul M Jones <pmjones at ciaweb.net> wrote:
> >
> > 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>
> >
> >
> >
> _______________________________________________
> Solar-talk mailing list
> Solar-talk at lists.solarphp.com
> http://mailman-mail3.webfaction.com/listinfo/solar-talk
>

-- 
IAN SZEWCZYK
ian at roamzero.com
roamzero at gmail.com
iaszew01 at louisville.edu