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

[Mark Wu]

Acutally, some people complains about the pLog in Taiwan and China.

BlogChina develop their own version based on pLog 0.32, but their speed is
damn fast ... Why?
1. They do refoactoring of pLog code ==> Acutally, they de-oo the pLog code
... So it is not pLog anymore,
2. They also denormalize the pLog DB, conver the DB back to 1NF only

I discuss these with Pixnet's (2md Big Gallery service in Taiwan) owner he
gave me the same suggestions.  He also suggest me:
1. Make the pLog_articles_text smaller to fasten the sql query. He suggest
we can separate the pLog_articles_text to several tables like
pLog_articles_text1,pLog_articles_text2,pLog_articles_text3...pLog_articles_
text16.  When user save the post, we dispatch the post the these tables
equally. So, we can have 16 small tables instead of a big table.
2. Analysis our code, find the bottleneck ===> wrtie the code in c, as a php
extension

But, in my mind, I really don't want to de-oo pLog. I am very ENJOY develop
the plugins based on current MVC framework, if we de-oo  .... I will be very
said ...

I am not so familiar the OO concept and architecture, but I do enjoy write
code with pLog :P

Mark

-----Original Message-----
From: plog-svn-bounces at devel.plogworld.net
[mailto:plog-svn-bounces at devel.plogworld.net] On Behalf Of Benjamin Krause
Sent: Tuesday, April 05, 2005 4:48 PM
To: oscar at renalias.net; plog-svn at devel.plogworld.net
Subject: Re: [pLog-svn] Branch plog-1.1-ben - callgraph 1.1-ben

Oscar Renalias wrote:

> 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.

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..
:(

> 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.

i'm not sure if removing the object inheritance will speed up the code, but
we might try :)

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 :)

but its a good thing to think about every aspect of the product, maybe we
can figure something out..

and afterall, its just speed.. as long as noone is complaining about pLog
being to slow we might not do to much refactoring ..

I'll continue my work in plog-1.1-ben and wait for your comments..

Ben


_______________________________________________
pLog-svn mailing list
pLog-svn at devel.plogworld.net
http://devel.plogworld.net/mailman/listinfo/plog-svn