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

[Oscar Renalias]

"dee-OO"izing our code is a no go. We haven't spent almost 2 years
working in a nice and clean OO framework only to throw it away as soon
as we are given the chance :-D However, we might need to get rid of
some of some nice OOP touches that slow down PHP's OO processing (too
much inheritance? proxy classes? simulated interfaces??)

I've also been thinking about denormalizing the db but that's no easy
task, even though if you look at some of the queries with 3 or 4
implicit JOIN operations... you'd get really scared. Obviously all
these things slow down but I am not that good at db design and
administration so perhaps there are a lot of things that can be done
but we're not aware of...

I would have liked to get some advice from blogchina but they decided
to go solo :(

Oscar

On Apr 5, 2005 3:39 PM, Benjamin Krause <ork at orkland.de> wrote:
> Hey Mark ..
> 
> Mark Wu wrote:
> > 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
> 
> mhh.. can we get a copy of their code? just wondering what they have
> done.. but i guess we're all agree that we won't "de-OO" pLog :)
> 
> > 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.
> 
> i don't think we should split the pLog_articles_text table. however i do
> agree that this table might be to slow if you have a lot of data ..
> the most obvious indexes have been created already.. not sure if they
> were present in 0.32 as well..
> we need to look into this, some of the (joined) selects might be to
> slow.. and we can activate caching for article_texts as well..
> 
> 
> > 2. Analysis our code, find the bottleneck ===> wrtie the code in c, as a php
> > extension
> 
> i don't like c :)
> but i agree that it is faster.. don't think we should go this way though..
> 
> > 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 ...
> 
> at least i dont want to see you sad :)
> 
> > I am not so familiar the OO concept and architecture, but I do enjoy write
> > code with pLog :P
> 
> Ben
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.plogworld.net
> http://devel.plogworld.net/mailman/listinfo/plog-svn
>