[wp-hackers] GSoC Proposal: Integrate WP-cache / WP Super Cache
into WordPress
Eric Marden
wp at xentek.net
Sun Mar 2 20:03:15 GMT 2008
> 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
More information about the wp-hackers
mailing list