Max Rydahl Andersen wrote:
I know i'm disconnected from the internals - but this is not news
is it,
everyone knows aop and vfs are the one spending most time (at least I
have been told that endless times when asked how I can make AS 5 start
as fast as AS 4) ?
Well we knew we had issues there, but we did not definitively know if
there were other factors. These numbers seem to suggest the hunch is
accurate.
What would be more interesting is to see what packages float on top
based on how much their computational time is spent in aop/vfs ?
i.e. is it not more likely that some layers above is using vfs/aop
wrong/badly/inefficiently ?
Just thinking out loud...
Yes, we should do that as well.
Optimizing things in vfs/aop is of course all good since that will
benefit all, but maybe it's certain modules usage of these layers that
are the problem.
This is most likely the case with at least the VFS issues, since we know
that we have multiple passes happening from calling code. We have to
look at the AOP usage in more detail, and try and remove it from areas
where it's not really needed.
p.s. this is similar to how I optimized hibernate startup time - if I
just looked at the raw numbers I would blame classloading in the vm to
be the
culprit since that is where 12-20% of our time is spent - but looking
closer it is because Hibernates current design required full access to
all classes
it would persist upfront, instead of doing it "on-a-need-to-know" basis.
Unfortunately that couldn't be changed in Hibernate 3 at the time without
major breakage to public API's ....
Ugh. Yeah, catching/correcting these issues long after major releases is
always a pain.
--
Jason T. Greene
JBoss, a division of Red Hat