Dieter,
this sounds very interesting.
The idea of creating such application that are "shared" between desktop and web has always appealed me and I was wondering how to implement it.


So I would be very interested
- that your patches make their way to the Zope core (I am not a Zope core contributor tough)
- to learn more about what you have done.


Robert

Dieter Maurer wrote:
Dear Zope developers,

we have used Zope+CMF+Archetypes in a new way -- not
as a Web Application framework but as a framework for
desktop applications that share a large part of their
functionality with online applications (implemented with Zope+CMF+Archetypes).

A major stumbling block has been Zope's incredibly high startup
time. We observerd times in the order of a minute on computers
with either slow CPU or slow IO. This may be acceptable for
a Web server but is prohibitive for a desktop application -- especially
as the predecessor application started within a few seconds.

To overcome this obstacle, we tweaked Zope and fixed Python's import
mechanism such that Zope now starts either out of a ZIP archive
or as a frozen application. These measures had the following results.

 Startup times on a mid range computer (AMD Athon 1.4 GHz; 512 MB memory)
 with a standard IDE disk.

                    Cold start                      Warm start
                (after computer startup)        (most files in OS cache)

   File system         13s                            5s
   ZIP archive          8s                            4s
   Frozen               5s                            3s


In more details, we did:

 *  implement a package for a new kind of "url"s "pypackage:"
    for package relative access to resources.

    The package monkey patches Python's "open", "os.listdir",
    "os.stat" to provide transparent access to
    "pypackage:" identified resources.

    It currently support package relative access for
    packages loaded from the file system, from a ZIP
    archive and from the executable itself (i.e. frozen packages).
    In the last case, the resources are in a separate ZIP
    archive.

    This package might be interesting for Python as a whole
    as it is not Zope specific.

 *  implement a shared object importer to be used
    as a Python "meta_path" hook.

    This importer allows to load shared objects into the context
    of a parent package (such as e.g. "ZODB.TimeStamp") although
    the shared object is not located inside the package's source
    (ZIP archive or executable).

 *  fix about 70 occurrences in Zope code where
    package relative access was implemented by "dirname(__file__)"
    to consistenty use "package_home".

 *  modify about a dozen places in Zope+CMF to use
    "pypackage:" and cope with "__path__" not being a list
    for frozen packages

 *  fix a few products (Archetypes and friends, TextIndexNG2,
    PlacelessTranslationService, ...) to use
    "package_home" (rather than "dirname(__file__)") and
    not to change the current working directory (which obviously
    would fail for destinationsbe in a ZIP archive
    or the executable).

 *  implement lazy loading of "ImageFile"s to
    reduce the risk of recursive imports (and reduce startup time).

 *  support lazy product initialization

 *  support configuration from a pickle file (to avoid
    expensive parsing of the schema and configuration files).

    The pickle is used as a configuration cache.

 *  fixed Python's import mechanism not to treat ZIP
    archives as a directory when the archive could not
    find a module.


If you were *really* interested in these startup time improvements, I could provide patches which might be integrated in the Zope core for e.g. Zope 2.9.



_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to