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. 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 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. Best, Mike From: Eddie Epstein <[email protected]> To: [email protected], Date: 06/25/2013 10:13 AM Subject: Re: [jira] [Commented] (UIMA-3017) Getting feature value from feature structure longer than expected I've noticed that java will optimize out code that does nothing. That may be apparent to the JIT with the pojo loop for (long i = 0; i < iterations; i++) { myInstance.getMemberStringValue(); } but not apparent with the deeper path thru the JCas/CAS code. Are you sure something like that is not happening here? That being said, the UIMA CAS design was strongly based on two principals: 1) to separate access APIs from the implementation, and 2) to enable standardized and high performance CAS serialization methods between analytics running in different Java versions and in non-Java platforms. Both principals incur CAS access performance penalties.
