Yuri wrote at 2005-5-19 18:01 +0200:
I'm doing an import of a large .zexp (from ZMI), and I see thay Zope is
first loading it all in memory, than doing the work of importing it!
How do you see this?
In fact, Zope does not work this way.
Instead it reads the zexp incrementally and as it reads builds
the Python object described by it.
But, it may not make that much of a difference.
Due to its persistency design, Zope must keep everything
in memory until a [sub-]transaction boundary.
As the Python object is likely to have a size in the order
of that of the zexp, your memory requirement is in that order.
I
mean, isn't it a little bit *inefficient? :)
What do you expect?
Also, renaming a folder with a lot of zclasses in (40.000), takes a lot
of time. After 10 minutes, it was still there... and this is a 2,4 Ghz
P4 and 512 MB of Ram...
Zope objects are often identified by their paths.
Thus, if you rename some node, then the path of this node
and all its descendants is changed. To allow for the necessary
updates, Zope calls manage_beforeDelete followed by manage_afterAdd
for the renamed node and all its descendants.
This makes an operation expensive, you deem to be inexpensive...
Can this be fixed/improved? :)
In principle, yes -- provided you do nowhere identify Zope objects
by their path. Especially, you do not use a (standard) catalog
(which does identify objects by their path).
When you know that nothing in your application depends on the path,
then you can override manage_renameObject to perform
the renaming without the call to manage_beforeDelete and
manage_afterAdd.
Expect some minor non-trivialities...
--
Dieter
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
