[EMAIL PROTECTED] schrieb:
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.
That's a good point. In fact, caching the filename already reduces the
performance penalty a lot. I added an MRUMemoryStore which caches the
file:// URI for a fallback:// source URI. The publication ID is added as
a prefix to the cache key.
The store is disabled by default, there's no GUI to clear it yet.
-- Andreas
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
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
