Re: [Collective-commerce] State of PloneMall

[Philipp A. <ph...@bl...>]

I agree here, the problem lies in the dynamic aggregation of schemata.
We have to think about a better implementation of dynamic schemata here.

Ive read in the mailinglists that Andreas Jung et al. made some good 
progress in
peeling out the dynamic schema from PCNG so that this will be available for
integration into other projects. This will propably the way PloneMall 
goes for.

for the short, its sufficient if you remove VariableSchemaSupport from 
PloneMallItem.SimpleItem's
inheritance list.

regards
phil


Simon Pamies wrote:

>On Friday 08 October 2004 10:56, Simon Pamies wrote:
>  
>
>>On Thursday 07 October 2004 19:56, george donnelly wrote:
>>    
>>
>>>Sune Broendum Woeller <sun...@sy...> on 10/7/04 wrote:
>>>      
>>>
>>>>About the cpu stuff, well, thats a plone-problem I
>>>>think - Plone really likes to eat a lot :)
>>>>(Plone could really use some optimizing here.)
>>>>        
>>>>
>>>no, actually  plone does use *that* much cpu when implemented properly.
>>>The issue i report is with plone mall beta 2.
>>>
>>>no one believes the cpu issue i report is real, but then no one seems to
>>>be using beta 2, either.
>>>      
>>>
>>a) I believe in the cpu issue, cause I've seen that thingy ;-) ... but...
>>that's not PloneMall's fault imo - PloneMall is using very much AT stuff
>>and 'relied' on some Memory Leaks introduced by the Placeless Translation
>>Service, cAccessControl and AT. After having updated ram usage decreased by
>>about 30% - PloneMall's running fine now :-)
>>    
>>
>
>NOW I believe in the cpu/time issue ;-) I've done some profiling and debugging 
>and IMO found the issues. After havin' "fixed" some code the speedup is from 
>33 secs to 4 secs !! The problem is inside some getSchema and others: They 
>try to aggregate Schema information by Traversal. Some of them get called 
>about 176000 times (ex. editing of CustomerInformation)  - that's slowing 
>down the system considerably, cause building a new Schema invokes 
>__add__(self, field, name)  and a bunch of other methods for each field at 
>every call....
>
>I need to have a deeper insight before I can come up with a patch :-)
>
>  
>