[Zope] zmi issues

[Dieter Maurer]

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