sorry for the late reply, been busy otherwise...
Andreas Hartmann wrote:
Hi Lenya devs,
I did some profiling during the last weeks. One of the most expensive
operations in Lenya is resolving fallback:// URLs, for the following
reasons:
1. The URLs are context-sensitive.
Resolving a fallback URL requires knowledge about the current
publication. Currently this is done by the Avalon Contextualize
mechanism. Because of this, the FallbackSourceFactory can't be
ThreadSafe, and needs to lookup its services upon each source resolving,
which is a quite expensive operation.
true. but from a user POV, fallback is just beautiful.
A possible solution would be to pass the ID of the current publication
to the fallback URL, for instance
fallback://{pubId}:xslt/foo2bar.xsl
This would also fix the template-fallback problem described in
http://issues.apache.org/bugzilla/show_bug.cgi?id=40564.
hmmm. i think this is quite ugly. why mess up the user-visible part of
the fallback api with redundant information? can't we rather attach the
publication information to the session as an intermediate measure?
i'd hate to clutter the fallback semantics with performance hacks that
work around avalon problems, especially since cocoon is moving to
spring, where such things are a lot cheaper i'm told.
Unfortunately we can't make this optional, because the
FallbackSourceFactory is either ThreadSafe or not. But in a first step
we could introduce an additional protocol, e.g. pubfallback://. I
implemented this as a prototype in my sandbox, and it seems to work
fine. We can also do this if we defer the implementation until after the
release and recommend to change the URLs for better performance.
i'm not happy with this. fallback:// is part of our user interface imho,
and as it is now, it's great and fun to use. pubfallback:// sounds
contradictory to me.
2. Checking the existence of the sources is expensive.
For each fallback source resolving, we check the existence in each
publication of the hierarchy, up to the core. This is of course quite
expensive. We could keep this for the "development" mode, and introduce
a "production" mode which caches all locations until the cache is
cleared manually.
isn't fallback cacheable? i.e., if a source is requested twice,
shouldn't it come from the cache the second time? so how would your
additional cache make a difference?
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
