[pLog-svn] Branch plog-1.1-ben - callgraph 1.1-ben

[Allan Sun]

Well I would like to put my little simple comments here.

As a developer outside the core team of Plog project, I gained a lot
of beniffit from plog's nice MVC architecture, I've got a chance to
look deep inside of the programme, I think the biggest weekness again
is the architecture itself.

This is actually a very common problem hanppens to every fast growing
software: people want it to be more powerful, and QUICK, so they just
quickly throw in their existing experience and the programme grows
very quickly, and then... you see, some complains comes about the
speed.

To me I think we really need to review our architecture at this point,
I did a simple check last night before I went to bed, I just realized
that for a simple DefaultAction, there were 188 files been loaded, you
know what? I just said WOWOOOO to myself, that really supprised me...
Imagine what gonna happen when 100 guest browsing the web site at the
same time? 18800+ files to be loaded! And the parsing and processing
are not included!

I'm not sure how are we implementing the blog processiong ( I always
use the plog framework but not the plog's blog funtion), but I
thought, do I really need to have the email service when I read the
somebody's blog? Shouldn't this service be included only when sombody
post some comment or something like that? This happens to every where
of plog.

So followed the discussion, I somehow agree with the idea of using
class loader, but this will involve some more computing on finding the
correct class, I believe it would be faster for small website, but
again that's not for enterprise application.

My suggustion is really - refactoring! I do belive there are loads
stuff we can do to improve the quality of the programme. I think what
we need now is a good architecture but not any tricks on fast
processing.

On Apr 5, 2005 9:47 AM, Benjamin Krause <ork at orkland.de> wrote:
> Oscar Renalias wrote:
>=20
> > I'm getting more and more convinced that php is not suitable for this
> > kind of heavily OOP-(over?)designed PHP apps. It runs ok but we keep
> > bumping into all this sort of issues that don't really leave a good
> > taste in your mouth... You try to design a nice API to make your
> > development easier and it turns out that spaghetti code will always
> > run much faster than your architecture. I mean, is really PHP/Zend
> > encouraging proper development techniques? Can't they really decrease
> > the penalty/overhead resulting from creating classes, calling parent
> > constructors and in general, making method calls? I really don't get
> > it.
>=20
> Its interpreted .. that's the main problem.. using the zend optimizer
> might help.. but then again, using java is the only good decision :)
> i guess it depends on the target group again.. most of the people you're
> targeting at don't know how to setup and admin a tomcat. most of the
> low-cost webhoster offer apache, not tomcat.
> actually its quite easy to deploy a .war file, but time is not right
> yet.. :(
>=20
> > On the other hand, let's see what we can do to fix it. Reorganizing
> > the includes is a first good step (though I would pay for an improved
> > "new" operator that loads classes dynamically based on something like
> > a CLASSPATH) and probably we'll have to find a few more tricks like
> > this. Also, how about giving up our nice hierarchy where everything
> > inherits from Object? We could remove that inheritance requirement and
> > only extend if really necessary. (only in cases like Action, or View,
> > etc) I am sure it would help.
>=20
> i'm not sure if removing the object inheritance will speed up the code,
> but we might try :)
>=20
> as far as i've seen it, not executing the code slows everything but
> loading and syntax checking. we might go for a dynamic classloader, not
> sure how to implement something like that ..
> i've seen your code to dynamically load classes in PluginManager.. but i
> don't if we can extend this to a level where we can load all classes
> dynamically.. beside the speed issue, require_once() is damn fast :)
>=20
> but its a good thing to think about every aspect of the product, maybe
> we can figure something out..
>=20
> and afterall, its just speed.. as long as noone is complaining about
> pLog being to slow we might not do to much refactoring ..
>=20
> I'll continue my work in plog-1.1-ben and wait for your comments..
>=20
> Ben
>=20
>=20
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.plogworld.net
> http://devel.plogworld.net/mailman/listinfo/plog-svn
>=20


--=20
With kind regards,
Allan Sun

=CE=DE=C3=FB=D0=A1=CF=BA

07900984568
Sunajia at cninuk.com

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
Chief Editor,
CNINUK Online Magazine

4 Riddell Court
20 Albany Road
London
SE5 0DS

www.cninuk.com
=C8=AB=D3=A2=BB=AA=C8=CB=B6=E0=CE=AC=C9=E7=C7=F8
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D