[
https://issues.apache.org/jira/browse/UIMA-5168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marshall Schor closed UIMA-5168.
--------------------------------
Resolution: Later
> uv3 vs backporting most things to uv2?
> --------------------------------------
>
> Key: UIMA-5168
> URL: https://issues.apache.org/jira/browse/UIMA-5168
> Project: UIMA
> Issue Type: Question
> Components: Core Java Framework
> Reporter: Marshall Schor
>
> The uv3 docs - overview has a summary of the "features" / benefits of uv3. I
> was surprised to realize, looking at these, that most of these could be
> back-ported into version 2.
> Because of this, there is a choice in moving forwards, either to stick to the
> current v2 data representation models (sticking), or switch to new v3 ones
> (for Java). In the subsequent discussion, "sticking" refers to a currently
> non-existent v2 where the v3 improvements (except for changing how Feature
> Structures are stored) are backported.
> The two benefits lost in sticking are:
> * garbage collection of unreferenced Feature Structures.
> * larger limits on the number of Feature Structures per CAS (approximately
> order of magnitude). This is due to the fact that in v2, all of the slots
> for all Feature Structures and int and float arrays are kept in one int
> array, which has a limit of approximately 2 billion words.
> Benefits in sticking include:
> * (perhaps) better backwards compatibility
> * a smaller memory footprint if JCas is not being used (imagine UIMA running
> on a smartphone)
> * (maybe) better performance in some cases, including serialization
> Regarding performance differences: v3 may be more performant in many cases
> because of not needing to switch from low-level int handles to JCas object
> references. But it may be less performant in some operations involving
> serialization, because of the overhead to emulate/model the way v2 does
> serialization. New Native-to-v3 serializaton forms that are not backward
> compatible could be added to v3 to overcome this.
> The things that could be backported to v2 include:
> * redesigning the JCas cover classes for higher performance (eliminating the
> xxx_Type classes, putting an extra field in the xxx cover class instead).
> ** note: a JCas class migration would be needed for this, similar to the one
> for v3.
> * redesigning much of the supporting infrastructure to improve performance by
> increasing locality of reference.
> * supporting arbitrary Java Objects, and backporting the implementation of
> FSArrayList and IntegerArrayList
> * integrating with Java 8 - including the new select framework
> * eliminating problems with ConcurrentModificationException while iterating
> over UIMA indexes
> * reusing Type Systems
> Comparing v3 versus v2+backport, what do people think of the balance between
> pro/con? Should we focus on a v2+backport direction instead of v3?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
