On Mon, 9 Jul 2001, Stuart Roebuck wrote:
> 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.
>
One commonality, IIRC - both Windows and MacOS are case insensitive.
The servlet spec (at least in 2.3) mandates case sensitive comparisons for
web app resources. The only way we've discovered to do that is to rely on
getCanonicalPath().
> >> 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/>
>
Craig
