1.3 has fallback built into the module: protocol.  The filename chosen
is cached.  Subsequent calls check that filename using File.exists()
before searching again.  The double-colon syntax (module::///filename)
is available to reset the cache for a Module, and is expected to be
useful for development and for functions that create local files in a
Module, which will be needed when online editing of Modules is
possible.

I dislike expecting the dev environment to differ from production.
Caching the filename rather than the contents avoids issues with the
file being changed.
I agree expiration is poor design.

solprovider

On 2/1/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> Hi Lenya devs,
>
>  yesterday I did some profiling again. IMO it's crucial and quite urgent
>  to improve the performance, especially of the authoring environment.
>  The biggest performance penalty is caused by the resolving of fallback
>  sources. They aren't cached by default, because a cascade of files is
>  involved and for each resolving of the source the system checks if a
>  file in this cascade has been added or removed.
>
>  As a proof of concept, I added an LRUMap as cache to the
>  FallbackSourceFactory. This improves the performance a lot. In
>  combination with the Ajax menubar the authoring environment feels
>  notably faster.
>
>  Unfortunately I don't see a way to prune stale sources from the cache
>  automatically. We could either add a button to the GUI which allows to
>  clear the cache when a static resource (sitemap/XSLT/...) has been
>  changed. IMO this would be useful and sufficient. Additionally, it could
>  be triggered by the build process.
>
>  Another option would be an expiration time, though I don't like this
>  idea much because it makes testing very cumbersome (you have to wait
>  after deploying something to see the results).
>
>  In development mode, the fallback:// source cache would be disabled anyway.
>
>  Do you think this approach is useful? I'll do some more testing and
>  provide a patch asap.
>  Andreas Hartmann, CTO

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to