[
https://issues.apache.org/jira/browse/LUCENE-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745724#action_12745724
]
Tim Smith commented on LUCENE-1826:
-----------------------------------
without the Tokenizer.reset(Reader, AttributeSource), i won't be able to reuse
Tokenizer instances (will have to create a fresh one each time)
this can get costly if each Tokenizer is layered with a bunch of TokenFilters
obviously, adding this method would be nasty (and impose additional
requirements on TokenFilters/Streams) but it would allow reusing the token
streams to the utmost
Question:
Is the reflection penalty on the new TokenStream stuff incurred per root
AttributeSource?, or per TokenFilter/TokenStream?
that is, if i pass the same AttributeSource to 10 TokenStreams, is the
reflection cost the same as if i passed it to just one?
> All Tokenizer implementations should have constructors that take
> AttributeSource and AttributeFactory
> -----------------------------------------------------------------------------------------------------
>
> Key: LUCENE-1826
> URL: https://issues.apache.org/jira/browse/LUCENE-1826
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Analysis
> Affects Versions: 2.9
> Reporter: Tim Smith
> Fix For: 2.9
>
>
> I have a TokenStream implementation that joins together multiple sub
> TokenStreams (i then do additional filtering on top of this, so i can't just
> have the indexer do the merging)
> in 2.4, this worked fine.
> once one sub stream was exhausted, i just started using the next stream
> however, in 2.9, this is very difficult, and requires copying Term buffers
> for every token being aggregated
> however, if all the sub TokenStreams share the same AttributeSource, and my
> "concat" TokenStream shares the same AttributeSource, this goes back to being
> very simple (and very efficient)
> So for example, i would like to see the following constructor added to
> StandardTokenizer:
> {code}
> public StandardTokenizer(AttributeSource source, Reader input, boolean
> replaceInvalidAcronym) {
> super(source);
> ...
> }
> {code}
> would likewise want similar constructors added to all Tokenizer sub classes
> provided by lucene
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
