[wp-hackers] GSoC Proposal: Integrate WP-cache / WP Super Cache into WordPress

[Eric Marden]

> Lazy Load looks interesting, but I don't know how applicable it would
> be to the current WP structure.

I thought that might be the case.

> It seems to be geared for the
> more-heavily object-oriented languages/projects out there where all
> the methods are parts of objects in the first place, and objects are
> embedded within objects (class members) for a fully OOP, cascaded
> development style.


Zend_Framework utilizes this quite a bit so I wouldn't say it is a  
language thing (php's OO shortcomings aside). But the concept of  
loading when needed, instead of all at once seems to be a good way to  
cut back on memory usage. The increase in performance from this, as  
applied to the current WP, is probably debatable, but maybe worth  
discussing.

> In our case, the performance problem isn't with the objects being in
> the memory so much as it is the functions to get them....

Maybe this is something that might tie in to a broader discussion of  
re-architecting with PHP5...?

-e


On Mar 2, 2008, at 2:14 PM, Computer Guru wrote:

> On 3/2/08, Eric Marden <wp at xentek.net> wrote:
>> Does WP use the Lazy Load design pattern, and if not would it make
>>  any sense to do so?
>>  http://www.martinfowler.com/eaaCatalog/lazyLoad.html
>>
>>
>>  -e
>>
>>
>>  On Mar 2, 2008, at 10:41 AM, Lloyd Budd wrote:
>>
>>> On Sun, Mar 2, 2008 at 7:31 AM, Andy Skelton <skeltoac at gmail.com>
>>> wrote:
>>>> On Sun, Mar 2, 2008 at 1:06 AM, Computer Guru
>>>> <computerguru at neosmart.net> wrote:
>>>>>  I understand the difficulties of making flexible-yet-well-
>>>>> performing
>>>>>  code. I know the tradeoffs between hard-coding stuff and having
>>>>> good
>>>>>  page-load-times. But at the end of the day, /caching is NOT
>>>>>  WordPress's biggest problem/, rather loading too many files at
>>>>> once,
>>>>>  using way more nested loops than it should, and not skipping
>>>>> certain
>>>>>  sections of the code when it can are what's responsible for WP's
>>>>>  "legendary" fear of the /. effect.
>>>>
>>>>  These are good points. The software could make better performance
>>>>  decisions early in the script. Can you work your ideas into a core
>>>>  patch?
>>>
>>> Failing that maybe Computer Guru you would be interested in  
>>> mentoring
>>> a student in that or a related project?
>>>
>>> It sounds similar to a couple of project ideas Matt included last
>>> year, but that we didn't have a student for:
>>> * A testing suite that measures performance of various components  
>>> and
>>> can be regularly run against new code.
>>> * Currently WP loads all its code on every page, could a selective
>>> code loading scheme improve performance in a meaningful way?
>>>
>>> http://codex.wordpress.org/GSoC2008
>>>
>>> Thank you,
>>> --
>>> Lloyd Budd | Digital Entomologist | | Skype:foolswisdom
>>> WordPress.com | WordPress.org | Automattic.com
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>>  _______________________________________________
>>  wp-hackers mailing list
>>  wp-hackers at lists.automattic.com
>>  http://lists.automattic.com/mailman/listinfo/wp-hackers
>>
>
> No, currently WP loads everything at the beginning and so it's always
> there when you need it.
>
> Lazy Load looks interesting, but I don't know how applicable it would
> be to the current WP structure. It seems to be geared for the
> more-heavily object-oriented languages/projects out there where all
> the methods are parts of objects in the first place, and objects are
> embedded within objects (class members) for a fully OOP, cascaded
> development style.
>
> Imagine:
> $blog.
> $blog->posts
> $blog->posts.filter_by(date,start,end);
> ...
>
> In that case, you could use the Lazy Load model to have posts called
> as you need them as the very simplest example. But the current WP
> model is more like
> $tag
> $posts = <query to get posts with this tag>
> $posts //retreived from the DB
>
> In our case, the performance problem isn't with the objects being in
> the memory so much as it is the functions to get them....
>
>
> I could be wrong, of course.
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers