On Tue, Jun 25, 2013 at 12:17 PM, Michael A Barborak < [email protected]> wrote:
> Hi, > > I added an access counter to MyClass that I incremented with each call to > getMemberStringValue(). I then printed that access count at the end of > each round. This was my result: > > Test 4. Get a member string from a POJO > 100000000 > round 0 total time 4: 0.109360998s > 200000000 > round 1 total time 4: 0.103437715s > 300000000 > round 2 total time 4: 0.103085417s > 400000000 > round 3 total time 4: 0.102891805s > 500000000 > round 4 total time 4: 0.101912657s > > Slower but in the ballpark. This seems to indicate to me that the code > isn't being optimized away. > Thanks for the confirmation. > > I guess I don't understand how the principles you mention must incur the > measured performance penalties. Or maybe you're not saying that? In > Actually, yes I am saying that these layers will incur some performance penalty. I don't how much the penalty for the current code can be reduced for all or even most scenarios. > particular it seems something like what I did for test 6 could be > implemented within UIMA rather than on top of it. I would suppose that > some optimization within UIMA might improve retrieving strings too. In any > case, I've deployed such optimizations in our application and seen a > performance improvement. > The JCas hashmap can have significant memory overhead, and for some applications where most FS are never retrieved within the same process the hashmap actually has significant CPU overhead as well. That's why the JCas hashmap can be turned off, or maybe it is turned off by default and can be turned on, don't remember :) Eddie
