- Removed the pickling of ZCML actions (the code that wrote

  ``configure.zcml.cache`` next to ``configure.zcml`` files in
  projects).  The code which managed writing and reading of the cache
  file was a source of subtle bugs when users switched between
  imperative (e.g. ``@bfg_view``) registrations and declarative
  registrations (e.g. the ``view`` directive in ZCML) on the same
  project. On a moderately-sized project (535 ZCML actions and 15 ZCML
  files), executing actions read from the pickle was saving us only
  about 200ms (2.5 sec vs 2.7 sec average). On very small projects (1
  ZCML file and 4 actions), startup time was comparable, and sometimes
  even slower when reading from the pickle, and both ways were so fast
  that it really just didn't matter anyway.

1 files changed, 0 insertions, 13 deletions

diff --git a/docs/narr/project.rst b/docs/narr/project.rst
index 5b15e9f44..2bd523aab 100644
--- a/docs/narr/project.rst
+++ b/docs/narr/project.rst
@@ -188,19 +188,6 @@ port 6543.
    development easier, as changes to Python code under
    :mod:`repoze.bfg` is not put into effect until the server restarts.
 
-.. note:: When :mod:`repoze.bfg` starts, it attempts to write a
-   ``.cache`` file which stores a cached version of your
-   :term:`application registry`.  In a typical setup this file will be
-   written as ``configure.zcml.cache`` in the same directory that your
-   application's ``configure.zcml`` is stored.  This is temporary data
-   that can help your :mod:`repoze.bfg` application start slightly
-   faster (its existence prevents the need to parse the XML stored in
-   the ``.zcml`` file if that file or any of files upon which it
-   depends files have not changed).  You can delete it at will as
-   necessary; it will be recreated.  If a ``.cache`` file cannot be
-   written due to filesystem permissions, :mod:`repoze.bfg` will just
-   reparse the ``.zcml`` file every time it starts.
-
 Viewing the Application
 -----------------------