lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Smith (JIRA)" <>
Subject [jira] Commented: (LUCENE-1826) All Tokenizer implementations should have constructors that take AttributeSource and AttributeFactory
Date Thu, 20 Aug 2009 23:28:14 GMT


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

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
> -----------------------------------------------------------------------------------------------------
>                 Key: LUCENE-1826
>                 URL:
>             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
> 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:
For additional commands, e-mail:

View raw message