sudeep87 / uimafit

Automatically exported from code.google.com/p/uimafit
0 stars 0 forks source link

Improve performance of selectCovered() using offsets #68

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Comment 5 by project member steven.bethard, Yesterday (30 hours ago)
For selectCovered(JCas, Class<T>, int, int), if it's currently slower than 
searching with an actual annotation instance, wouldn't it just be better to 
have it call:

    selectCovered(jCas, cls, new Annotation(jCas, int, int))

?

Comment 6 by project member richard.eckart, Yesterday (23 hours ago)
I am not sure calling new Annotation(jcas) already takes up memory in the CAS, 
that is why I didn't implement it like that. I am also not sure if the 
Annotation would need to be added to the indexes for that to work. 

Comment 7 by project member steven.bethard, Today (4 hours ago)
I don't know about the memory, but you don't need to add it to the indexes - it 
works fine without it in our AnnotationRetrieval code.

Original issue reported on code.google.com by richard.eckart on 18 Mar 2011 at 1:24

GoogleCodeExporter commented 8 years ago
If I understand CASImpl.createFS() correctly memory it the CAS is reserved 
immediately on creation of a FeatureStructure/Annotation. So simply creating a 
new Annotation/AnnotationFS for each select is not an option.

Also if I understand FSLeafIndexImpl.compare(int, int) correctly (this is what 
is eventually called by FSIterator.moveTo()), it only works with feature 
structures that have actually been added to the CAS, so creating a custom 
implementation of FeatureStructure just for seeking also won't work.

Original comment by richard.eckart on 11 Apr 2011 at 4:59

GoogleCodeExporter commented 8 years ago

Original comment by richard.eckart on 11 Apr 2011 at 5:02

GoogleCodeExporter commented 8 years ago
I disagree with the argument that because creating a new Annotation allocates 
some memory this is "not an option". We should certainly be allowed to trade 
memory for speed if that's what we want. I do agree it can't be the only option 
though.

Original comment by steven.b...@gmail.com on 11 Apr 2011 at 5:22

GoogleCodeExporter commented 8 years ago
I think its an option for whoever wants to do this, but I don't think such a 
thing should be encouraged by adding it to uimaFIT.

Original comment by richard.eckart on 11 Apr 2011 at 5:24

GoogleCodeExporter commented 8 years ago
How about adding it in the documentation for the method?

Original comment by steven.b...@gmail.com on 11 Apr 2011 at 6:20

GoogleCodeExporter commented 8 years ago
What do you think about adding a note to selectCovered(JCas, Class<T>, int, 
int) that a faster but memory-leaking alternative is to use selectCovered(jCas, 
cls, new Annotation(jCas, int, int))?

Original comment by richard.eckart on 11 Apr 2011 at 6:25

GoogleCodeExporter commented 8 years ago
Sounds great.

Original comment by steven.b...@gmail.com on 11 Apr 2011 at 6:31

GoogleCodeExporter commented 8 years ago
These issues are candidates for version 1.3.0.

Original comment by richard.eckart on 7 May 2011 at 5:31

GoogleCodeExporter commented 8 years ago

Original comment by richard.eckart on 4 Jan 2012 at 10:51

GoogleCodeExporter commented 8 years ago

Original comment by richard.eckart on 5 Jul 2012 at 4:02

GoogleCodeExporter commented 8 years ago
Added documentation to selectCovered as discussed.

Original comment by richard.eckart on 5 Jul 2012 at 10:08