[RT] Improving Dynamic Selection List performance inside Repeaters

[Antonio Gallardo <ag...@agssa.net>]

Hi:

Last night, I was playing with the new AJAX + a repeater with one dynamic
selection list (DSL). I noted the repeater builds the DSL on every row.
OK, this is old knowledge. But, when we have time expensive DB queries
needed to retrieve the DSL data, ie: each one takes cca. 1 second or more.
This is painfull slow with a 4 or more rows repeater. In short unusable.

I think we can somehow "cache" the data of the DSL or DSLs while we are
inside the repeater to improve the performance. This is an internal change
and in noway will affect the user API. Perhaps, if some people is against
and wants to have this "cache" behavior as an option, then we can define a
new attribute for the DSL. If people need it, we can set the default
behavior as it is now. Turn on an @cache="true" will set the DSL to use
the new cache. Or perhaps it is better to define it at the repeater level.
Well, we can discuss this once we define we need to set the new @cache
attribute.

The cache should have a short life. In order the save memory, the data
should be dropped once the form is finally rendered. It will read the DSL
data once and serve them from the cache while we are on the same repeater
(or form? - again we need to define the level of this behavior).

I am not really sure if this is viable and how much time we can save using
a short lived cache. But somehow we need to improve the cforms
performance.

WDYT?

Best Regards,

Antonio Gallardo.

Re: [RT] Improving Dynamic Selection List performance inside

[Ralph Goers <Ra...@dslextreme.com>]

Antonio Gallardo wrote:

>
>OK. Perhaps the sample is not the best, lets forget about the database.
>The fact is that selection list is requesting the pipeline per row. Hence,
>triggering all the pipeline and all the process that it involves. And
>there is where I see a waste of time. In the static selection list, this
>does not happen at all. Cforms read the data once and then serve from is
>own store or cache. I think this is a lot time faster.
>  
>
Well, yes. Invoking a pipeline per row would be awful.

>In fact I am using OJB and since I am the only user (I am testing in my
>own machine) I know the data are cached from the OJB cache. There is no
>direct request to the database, where BTW, there are also cached (Again, I
>am the only user). But this is still slow to my taste. Please don't
>answer: "Just buy a faster processor and more RAM!". ;-) lol.
>  
>
No, I agree with you.

>  
>
>>If that is cached would the amount of time DSL
>>takes matter?
>>    
>>
>
>This is one of my concerns. And one of the reasons of my initial mail. I
>guess we can save some time by triggering the pipeline only once per
>request, storing the data somewhere in the selection list, and then next
>row will be served from the temporal cache. Thinking in that, it must be a
>lot times faster.
>
>  
>
I admit I have been wanting to get into CForms for a while. But what you 
are proposing makes sense to me.

>Best Regards,
>
>Antonio Gallardo.
>
>  
>

Re: [RT] Improving Dynamic Selection List performance inside Repeaters

[Antonio Gallardo <ag...@agssa.net>]

On Mie, 25 de Mayo de 2005, 21:44, Ralph Goers dijo:
> Antonio Gallardo wrote:
>
>>Hi:
>>
>>
>>I am not really sure if this is viable and how much time we can save
>> using
>>a short lived cache. But somehow we need to improve the cforms
>>performance.
>>
>>WDYT?
>>
>>Best Regards,
>>
>>Antonio Gallardo.
>>
>>
> Well, I'm not really familiar with CForms, but FWIW my first thought was
> that this doesn't sound like a problem with DSL, but with caching the
> model data it operates upon. Why would you go to the database every time
> you need the same data?

OK. Perhaps the sample is not the best, lets forget about the database.
The fact is that selection list is requesting the pipeline per row. Hence,
triggering all the pipeline and all the process that it involves. And
there is where I see a waste of time. In the static selection list, this
does not happen at all. Cforms read the data once and then serve from is
own store or cache. I think this is a lot time faster.

In fact I am using OJB and since I am the only user (I am testing in my
own machine) I know the data are cached from the OJB cache. There is no
direct request to the database, where BTW, there are also cached (Again, I
am the only user). But this is still slow to my taste. Please don't
answer: "Just buy a faster processor and more RAM!". ;-) lol.

> If that is cached would the amount of time DSL
> takes matter?

This is one of my concerns. And one of the reasons of my initial mail. I
guess we can save some time by triggering the pipeline only once per
request, storing the data somewhere in the selection list, and then next
row will be served from the temporal cache. Thinking in that, it must be a
lot times faster.

Best Regards,

Antonio Gallardo.

Re: [RT] Improving Dynamic Selection List performance inside Repeaters

[Ralph Goers <Ra...@dslextreme.com>]

Antonio Gallardo wrote:

>Hi:
>
>
>I am not really sure if this is viable and how much time we can save using
>a short lived cache. But somehow we need to improve the cforms
>performance.
>
>WDYT?
>
>Best Regards,
>
>Antonio Gallardo.
>  
>
Well, I'm not really familiar with CForms, but FWIW my first thought was 
that this doesn't sound like a problem with DSL, but with caching the 
model data it operates upon. Why would you go to the database every time 
you need the same data? If that is cached would the amount of time DSL 
takes matter?

Ralph