[Zope] Problem: performance of retrieving properties from objects...

Antwan Reijnen twanus@xs4all.nl
Sat, 06 Apr 2002 11:31:12 +0200


Hi Lennart!

Thanks for your prompt thoughts. Let me elaborate on some points:



>The depends entirely on what the data retrival methods are...

I use two methods: one 'official' one: propertysheet.propertyItems(), and one I wrote myself, which fetches the properties loop-wise with propertysheet.getProperty(id). The time they require, is roughly the same...





> > 2) Suppose I have to switch to a database (there goes my weekend and free
> > evenings next week). I want to retrieve the properties as one record then.
>I
> > think the number of 400 props will decrease in this matter, too.
>
>Why would they decrease just because you move them to a relational database?

Quite af few properties are 'lines' and 'selection / multiple selection'. I guess when I use a rdb some of this zope-specific properties won't be nessecary.






> > I assume the database will retrieve these results a LOT faster.
>
>That depends on the database... And it depends on why it is so slow. I think
>the fact that you have so many properties add to the slowness, since each of
>then has to be looked up. 

Agree, but consider this: when I retrieve a fixed set of data, on propertysheets with varying number of properties (N), the fetchprocedure takes more time when N increases... Why should propertysheet.getProperty('aProperty') take longer on a larger propertysheet?





>So a database would be faster here, since they
>have a fixed data structure. On the other hand, you might get the same
>effect by radically altering your data structure. Which brings us to the
>main question:
>
>***Why on earth do you have 400 properties?***

I already drastically REDUCED it. I made 6 categories (propertysheets) which makes about 400 properties per propertysheet :-)) Each sheet contains 13 questions with lots of answerfields. I already told my boss that these kinds of large questionaries will not work in practice (BORING), but... you know, he is the boss ;-)





> > How about using this database in combination with an existing catalog?
>
>It can be done, but is not necessary. Index the data in the database
>instead.

Ok. This way I have two different searches on the website, but that's acceptable.




> > 3) Suppose I build a CMF product entirely in python (may god help me), and
> > I store all these properties as mentioned in (1), would the performance be
> > higher than in case (1)?
>
>Python classes are supposedly faster than ZClasses (I don't use ZClasses, as
>I find them complicated, limited and cumbersome), so yes it would probably
>be faster, but I can't say how much



Ok, thanks again Lennart. If you have the time to enlighten me further, you are more than welcome!!

Many greetings from the Netherlands, Antwan.