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