[
https://issues.apache.org/jira/browse/LUCENE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781233#action_12781233
]
Robert Muir commented on LUCENE-2090:
-------------------------------------
Michael, here is one idea that isn't too crazy.
separately i think we should make it convenient for a MTQ to get a char[], this
should not change.
however, lets consider this:
{code}
/**
* Returns true if the given string is accepted by this automaton.
*/
public boolean run(String s) {
int p = initial;
int l = s.length();
for (int i = 0; i < l; i++) {
p = step(p, s.charAt(i));
if (p == -1) return false;
}
return accept[p];
}
{code}
checking a string, is really just stepping thru one char at a time.
would 'incremental, one char at a time' conversion actually help, or do you
think it would just be slower?
conceptually, this isn't that much different than using a Reader with java i/o,
at a much smaller scale.
i am not familiar with decoding performance, but I thought I would mention
this, just in the case there is a way to do it clean.
> convert automaton to char[] based processing and TermRef / TermsEnum api
> ------------------------------------------------------------------------
>
> Key: LUCENE-2090
> URL: https://issues.apache.org/jira/browse/LUCENE-2090
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Robert Muir
> Priority: Minor
> Fix For: 3.1
>
>
> The automaton processing is currently done with String, mostly because
> TermEnum is based on String.
> it is easy to change the processing to work with char[], since behind the
> scenes this is used anyway.
> in general I think we should make sure char[] based processing is exposed in
> the automaton pkg anyway, for things like pattern-based tokenizers and such.
--
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: [email protected]
For additional commands, e-mail: [email protected]
