[jboss-dev] Further profling: Where should I focus?

[Brian Stansberry]

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