I assume you talking about this.svd.useFSCache :-) This has been disabled for as long as I can recall.
If enabled, it saves the Java cover objects for all referenced Feature Structures in an array, which is the same size as the CAS Heap. Note that a CAS holding, say, 1 million FSs, may have a heap size of 10 or more million slots (because the heap contains in addition to the type code for the FS, all of the features, or in the case of some arrays, the array contents). Cached FSs are also not Garbage collected (until the cache is reset); this can increase memory consumption (unless other things are holding on the generated Java cover class instance, anyways). The original thought had been that creating new FSs every time might be "expensive" in early versions of Java. With the new GC algorithms that make it less expensive to GC short-lived objects, it was felt that this was less of an issue. Ruta's use may be a special case, though... There is currently no option to cache FSs for just some types, other than to create a JCas cover class for those types and run with JCas enabled. -Marshall On 8/24/2015 7:42 AM, Peter Klügl wrote: > Hi, > > what is the current status on FS caching in svd? The comment says that > it is not maintained. If activated, an NPE is thrown because the fsArray > was never initialized. This could be solved by initializing it with a > non-empty array. (I could create an issue and fix it, if wanted). > > In my current (extremely restricted) test bed, the memory consumption > and runtime drop both by about 30% with fs caching. > > I do not have a overview yet: Could there be problems with other parts > of UIMA if we use the caching? > > with a big Ruta hat on: > Is it an option for us to active the caching on the fly for a specific > type only? > > Best, > > Peter > > >
