A place to record analysis and observations about the design represented by the Cas-obj prototype.
aspect | sub aspect | picture | space/time tradeoffs, locality-of-reference (L1/L2/L3 memory caching) | backwards compatibility | alternatives | notes | |||
---|---|---|---|---|---|---|---|---|---|
Data Storage | Where: Each FS's storage is represented by values as part of 1 Java object
| UIMA Feature Structure diagram | More space:
Faster: locality of reference high. Faster: operations (except for some needing FSids) won't need to use JCasHashMap to convert from int offsets in the heap to JCas cover objects. | for reduced space / FS could:
| denormalized: each has cas ref, type ref, typesystem ref | ||||
Data Storage | "fs-id" - an int (dense) representing the unique ID of a FS.
| ||||||||
Data Storage | Feature Structure representation: as 3 Java objects:
| The offset array is an object that roughly corresponds to the _Type object in the JCas, in that provides a way to get from a designated field to the offset. The JCas provides this as special named fields, part of the _Type object. The CasObj provides this as an int array object. The cas ref is used for "addToIndexes" to locate the view containing the indexes to be added to. The offset array is shared among all FS associated with a particular type system | cas ref is to one view; used for add/remove-indexes, getView, get the "fs-id" | ||||||
Data Storage | "get" and "set" operations for features
| ||||||||
Data Storage | JCAS _Type classes | These are not used, but are "supported" for backwards compatibility. Support includes their low-level APIs | |||||||
Data Storage | low level API support, including C++, binary (de)serialization | partially started, remainder TBD | |||||||
Views | FS obj has link to CAS -view it was originally created in; this is used for obj.addToIndexes style for add/remove | ||||||||
Indexes | Bag - structure |
|
|