gmane.comp.version-control.subversion.trac.devel

[Trac-dev] About #6436


Hi,

Forgot to ask around: does anyone foresee possible problems with this?

http://trac.edgewall.org/attachment/ticket/6436/cache-get_ticket_fields-r6843.diff

Summary: fixes the [query:...] slowdown by caching the result of 
Ticket.get_ticket_fields. There might well be lots of other situations 
where this speed things up, as the above operation was quite costly 
(e.g. 0.1 - 0.5 seconds) and is done at each creation of a Ticket or 
Query object.

Eventual issue would be a situation where the cache would be invalid - 
ideally the cached result should be read-only. I think this is the case 
in Trac 0.11, but in case that assumption is wrong (it is wrong for 
0.10), I return a copy of the list and a copy of each of its elements. A 
modification to a "deeper" structure (e.g. a list value) would however 
reach the cached stuff, so that would be a problem - but it should be 
considered a bug in the code  which does such modifications.

-- Christian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

(Continue reading)

headers

Noah Kantrowitz | 24 Apr 20:52

[Trac-dev] Re: About #6436


On Apr 24, 2008, at 2:37 PM, Christian Boos wrote:
>
> Hi,
>
> Forgot to ask around: does anyone foresee possible problems with this?
>
> http://trac.edgewall.org/attachment/ticket/6436/cache-get_ticket_fields-r6843.diff
>
> Summary: fixes the [query:...] slowdown by caching the result of
> Ticket.get_ticket_fields. There might well be lots of other situations
> where this speed things up, as the above operation was quite costly
> (e.g. 0.1 - 0.5 seconds) and is done at each creation of a Ticket or
> Query object.
>
> Eventual issue would be a situation where the cache would be invalid -
> ideally the cached result should be read-only. I think this is the  
> case
> in Trac 0.11, but in case that assumption is wrong (it is wrong for
> 0.10), I return a copy of the list and a copy of each of its  
> elements. A
> modification to a "deeper" structure (e.g. a list value) would however
> reach the cached stuff, so that would be a problem - but it should be
> considered a bug in the code  which does such modifications.

I would rather see what happens when we make the restrict_owner- 
governed fields load lazily. That seems like a bigger problem to me.

--Noah

(Continue reading)

headers

Christian Boos | 24 Apr 21:34

[Trac-dev] Re: About #6436


Noah Kantrowitz wrote:
> On Apr 24, 2008, at 2:37 PM, Christian Boos wrote:
>   
>> Hi,
>>
>> Forgot to ask around: does anyone foresee possible problems with this?
>>
>> http://trac.edgewall.org/attachment/ticket/6436/cache-get_ticket_fields-r6843.diff
>>
>> Summary: fixes the [query:...] slowdown by caching the result of
>> Ticket.get_ticket_fields. There might well be lots of other situations
>> where this speed things up, as the above operation was quite costly
>> (e.g. 0.1 - 0.5 seconds) and is done at each creation of a Ticket or
>> Query object.
>>
>> Eventual issue would be a situation where the cache would be invalid -
>> ideally the cached result should be read-only. I think this is the  
>> case
>> in Trac 0.11, but in case that assumption is wrong (it is wrong for
>> 0.10), I return a copy of the list and a copy of each of its  
>> elements. A
>> modification to a "deeper" structure (e.g. a list value) would however
>> reach the cached stuff, so that would be a problem - but it should be
>> considered a bug in the code  which does such modifications.
>>     
>
> I would rather see what happens when we make the restrict_owner- 
> governed fields load lazily. That seems like a bigger problem to me.
>

(Continue reading)