Remy & Craig,
Thanks for your responses...
On Saturday, July 7, 2001, at 07:28 am, Remy Maucherat wrote:
>> The cases you've described above all happen only once (at startup
>> time). Assuming that we could safely optimize these cases, would it
>> really make a significant difference?
>
> It wouldn't.
>
> While you were away, I did some profiling of the startup (since people
> complained), and it turns out that the time is mostly spent in :
> - Crimson, because it's used in validating mode
> - introspecting and doing various things in the XML mapper (no surprise)
The examples I gave were just some examples of getCanonicalPath that I
located in the source - I acknowledge that I had been unable to identify
which ones were taking up significant resources, though all the ones I
listed were at least in loops.
I have had problems profiling Tomcat and Cocoon, but in those threads I
have been able to profile under Mac OS X, getCanonicalPath (i.e. native
UnixFileSystem.canonicalize) calls whilst running Tomcat 4 and Cocoon II
constitute a *very* significant proportion of runtime. I know that others
have noted that this is also true under Windows, so this does not appear
to be specific to Mac OS X, though the 'cost' of getCanonicalPath under
Mac OS X may be proportionally higher than on other operating systems due
to certain underlying filesystem issues.
>> To influence the performance of Cocoon, we'd want to look at the
>> Resources
>> implementation. It's been worked on, but I would certainly not say we've
>> really optimized it yet. And reducing the number of calls to
>> getCanonicalPath() sounds like a good strategy -- as long as it can be
>> done safely.
>
> getCanonicalPath is called only under Windows (for case sensitivity
> checking).
> More profiling showed that the resources were fast enough.
>
> Remy
Remy - could you explain what you mean here. getCanonicalPath calls
within Tomcat are not, as far as I can see, conditional upon runtime
Operating System. Both Windows filing systems and HFS / HFS+ (Under Mac
OS / Mac OS X) are case insensitive, the latter being BSD Unix derivative.
I would have thought that calls to getCanonicalPath would be required,
not just for case sensitivity reasons, but also to deal with the
assortment of equivalent path descriptors, e.g. the use of "..", ".",
"~user" and the effects of filesystem softlinks, hardlinks, aliases,
shortcuts, or whathaveyou. If getCanonicalPath is being used as a case
insensitive string comparitor, then I am sure there are less costly
alternatives.
When you say that profiling indicated that resources were fast enough, do
you mean that getCanonicalPath is not a significant bottleneck on any
platform? I'm not doubting this with respect to Tomcat 4, as the main
issues I have run across may be largely Cocoon II specific, unfortunately
currently profiling problems mean that I'm going round the houses a
little to pin this one down. However, as I indicated in my earlier email,
I have tested substituting th java.io.File.getCanonicalPath() method with
a caching version and found a very visible speedup which confirms that
getCanonicalPath is an issue somewhere in this Tomcat 4 / Cocoon II
combination.
Stuart.
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
