David M. Lloyd wrote:
On 01/05/2010 04:39 PM, Bill Burke wrote:
>> This is a complex problem that you cannot paint with a broad
>> brush. You must look at each use case separately before you can say stuff
>> like "we need caching".
> Just to let you know, I did work on VFS and optimizations of VFS end of
> 2006 for a month or two. It used to do stupid shit like calculating
> path names each and every time you asked for it.
If you want the feature, you pay the price. The requirements are always
open for debate, I suppose.
We should definitely document these in a wiki, along with justification.
A crticial invariant that VFS has, based on it's usage patterns, is that
a VirtualFile reference or path always refer to what is "current". In
the FS case "current" means hitting the OS FS. In the JAR case it means
accessing a precomputed index that is constant. This is because various
AS components (e.g. ProfileService) and frameworks which operate on URLs
expect the path/instance to still be valid after redeployment. For this
reason VirtualFile in VFS3 is modeled after java.io.File, which also
always does indirection. As noted earlier, the cost of the indirection
scales linearly, is minor in comparison to other areas, and there is of
course always room for further optimization. VFS2 was inconsistent on
this approach and it was/is the source of many bugs.
Jason T. Greene
JBoss, a division of Red Hat