[pLog-general] It's about time... pLog 1.0 is out :-)

[Oscar Renalias]

On 1 Apr 2005, at 18:24, Benjamin Krause wrote:

> Hey ..
>
> Oscar Renalias wrote:
>> what do you mean when you say "to many lines of coded that are not
>> needed for most requests"?
>
> I think a lot of lines of code are loaded and executed that must not 
> necessariliy be called.

well we've got big data access classes that implement all the data 
logic behind articles, categories, blogs, etc. Of course if you only 
need to use Blog::getBlogInfo() you're going to load the whole Blog 
class, however big it is. There are many more examples like this and I 
don't see an easy way around that... unless we divide the code in even 
smaller files with even more dedicated purposes.

All said, I'm open to suggestions :)

> If we are going to implement some caching of db results or
> The caching of Smarty will only cache the output. Thats fine, but 
> that's just one part.. the view. I would like to cache in the business 
> layer as well. And i dont mean caching within a session, but within 
> the "webapp" as a whole.
> e.g. if you select the newest articles, why not dump the result of the 
> sql statement to disk and use that result for all requests of all 
> current session until someone acutally writes something in the db.
> there is to much memory neccessary to run pLog and its to slow in its 
> current state.
> I would like to reduce the memory and cputime by eliminating lines of 
> code that is not needed for the current request. either by caching 
> some results or by analysing the code and identifying code that is not 
> needed for the request, but gets loaded anyway.

ADOdb has some caching features that I tried to use, but they are 
useless. ADOdb will write the RecordSet objects as serialized data to 
files in disk and then retrieve them as they become necessary but in 
this scenario the disk was the biggest bottleneck (it was much slower 
than not using cache)

I am not sure how we can improve this situation but mysql already has 
its own in-memory query caches and if a query is repeated many times, 
it will use the cached version without us needing to worry about it.

Optimization of our own sql queries... well that's another topic :-)

>> I suppose this would come as an end result of implementing your first
>> suggestion :-)
>
> yeah :)
>
>> what advantages would Cache_Lite bring to the caching already
>> implemented via Smarty? Keep in mind that we don't need with caches
>> ourselves but it is left up to Smarty to handle those. We just let
>> smarty know that we want to use caching but that's all... Any changes
>> to the caching layer should be done to Smarty and that's quite a big
>> task in itself (and which I don't think we should undertake)
>
> am i wrong if i think the caching in Smarty is just for the 
> presentation layer?

yeah it's a the presentation level... but if you look at for example 
DefaultAction, you'll see that the first thing we do there is ask 
whether our view is cached. If it is, then we don't even bother loading 
the data and we go ahead with what was cached so we are saving a lot of 
processing time too.

Oscar