Very since :-)

I'll also bet that the CAS creation is faster? There are no ThreadLocals
yet in the Ruta tests.



Am 13.01.2017 um 04:56 schrieb Marshall Schor:
> An interesting comparison: The Ruta-core tests, for 2.5.0, run (on my laptop
> develop machine) in 48 seconds.  If I switch the Java to 8, it runs in 40
> seconds.  If I switch to Uima v3, it runs in about 23 seconds :-).
> This amount of speedup is perhaps unusual; I haven't really analyzed what's
> contributing to the improvement.  It could be many things, from better 
> locality
> of reference, causing significantly fewer memory cache misses (this is a key
> design goal of v3), and/or benefits from improvements in some of the 
> fundamental
> approaches for managing indexes.
> -Marshall
> On 1/12/2017 10:50 PM, Marshall Schor wrote:
>> I'm wondering how to do the version management for v3 style components.  
>> Here's
>> what I did for testing:
>> 1) I made a version of uimaFIT and Ruta for v3, and called them by some
>> different version number.  For instance, for uimaFIT, I started with
>> 2.3.0-SNAPSHOT (trunk) and made a version.  For Ruta, I 
>> started
>> with the 2.5.0 (tag) and made a version.
>> Having a separate version allows the builds to create separate sets of Maven
>> objects, which don't "overlay" the others.
>> The POM changes are:
>>   a) switching the Java version to 8
>>   b) depending on uima v3 (3.0.0-SNAPSHOT)
>>   c) Ruta has a property for the uima version, the uimaFIT version, both 
>> updated
>> to the appropriate versions.
>> I'm not sure this is the best idea about version numbers.  I suspect we will 
>> be
>> maintaining two version streams for a while, so perhaps having a uniform 
>> 3.x.x
>> for Ruta and uimaFIT would be good.  But it's also a bit of a pain to have 
>> two
>> versions.  I've managed to keep version 2.x and 3.x of UIMA more or less in
>> sync, using the svn "merge" command, which seems to work pretty well.  Maybe
>> there's a better way though...
>> ------------------
>> 2) A main change for using UIMA v3 is to have updated JCasGen classes.  Ruta 
>> and
>> some parts of uimaFIT use the maven plugin for JCasgen to generate the JCas
>> cover classes as part of the build.  This is ideal; no "migration" is needed;
>> just run the build and the v3 versions of the JCas classes are generated.
>> uimaFIT has some JCas cover classes that are not generated by the build, but 
>> are
>> in source code.  It would be simpler if these could be also generated.  If 
>> this
>> is not possible (perhaps because they've been "customized"), they can be
>> converted using the migration tool.  I did this for the uimaFIT classes that
>> were not generated by the build.
>> ------------------
>> 3) Some test cases that depend on the internals of V2 needed updating in 
>> uimaFIT.
>> 4) One test in Ruta creates pipelines in succession (using uimaFIT) and sees 
>> if
>> the type system is != to a previous one as a signal initialize some Ruta
>> representations of types.  In Version 3, equal type systems are consolidated,
>> and one of the tests had such, and so part of the Ruta initialization was
>> skipped, which caused an error.
>> 5) Some of the tests in Ruta using some internals of uima needed some 
>> tweaking.
>> -----------------
>> I'm planning on reviewing and checking in the uv3 changes tomorrow.  I guess 
>> we
>> need to figure out how to have a v3 version of uimaFIT / Ruta, either
>> temporarily in a branch, or some other way.
>> -Marshall

Reply via email to