Re: [jboss-dev] Further profling: Where should I focus?
On 01/05/2010 08:39 PM, Bill Burke wrote:
Bill Burke wrote:
> For example I just optimized VirtualFile.isDirectory(), isFile(), and
> getMount() to cache (and invalidate the cache on a mount). In addition,
> I modified VirtualFile.getChildren() to have the FileSystem create the
> list of VirtualFiles. Doing so, allowed me to pre-initialize the
> isDirectory cache of the VirtualFile. I just got a 12% improvement
> (30ms). This improvement was entirely within determinePackageNames, but
> still. 30ms * 3 (15 meg of jars) * 2 (Packages + Subdeploy scans) ==
> 200ms less of App Server boot time. Not much, but its a start.
>
Eh, I guess its all just splitting hairs. VFS3 is already a huge
improvement over VFS2. I guess I'll wait and see what the bottleneck is
in AS after AOP, VFS3, and deployer sorting is integrated with AS6 trunk.
Sorry for all the bickering. VFS3 looks great.
Any ETA on VFS3 being done and integrated with AS 6?
My guesstimate is very early in the M3 cycle (i.e. as soon as we open
trunk to commits after M2). So mid-February.
It's tempting to try for M2, but there's only 3.5 weeks left before
component integration freeze, this is a big disruptive change and there
are a couple issues to resolve:
1) Detecting modifications of exploded deployments:
http://community.jboss.org/thread/146098
2) This caching discussion, which IMHO should continue. It's legit to
think again about what the intended use cases are for VFS and see if its
API can be adjusted to more effectively handle those use cases.
The MC team is going to be putting out a 2.2 alpha release soon; while
that's being integrated in the AS and issues resolved over the next week
it makes little sense to try and start pushing in VFS3. So let's use
that time to resolve the modification detection issue and discuss a bit
more about caching. By the end of next week we should have a clearer
picture as to whether trying for M2 is feasible.
--
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat