Very since :-)
I'll also bet that the CAS creation is faster? There are no ThreadLocals yet in the Ruta tests. Best, Peter 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 2.3.0.3-SNAPSHOT version. For Ruta, I >> started >> with the 2.5.0 (tag) and made a 2.5.0.1-SNAPSHOT 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 >> >>
