On Dec 20, 2007 10:07 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
> Hmmm, I will have to take a look at Token.clone. I must admit I don't
> know a lot about the perf. differences between clone and new, but I
> would think the cost should be on par, if not a little cheaper,
> otherwise what's th
20 dec 2007 kl. 16.07 skrev Grant Ingersoll:
I must admit I don't know a lot about the perf. differences between
clone and new, but I would think the cost should be on par, if not a
little cheaper, otherwise what's the point?
My guess is that clone() is a convenience implementation that to
Hmmm, I will have to take a look at Token.clone. I must admit I don't
know a lot about the perf. differences between clone and new, but I
would think the cost should be on par, if not a little cheaper,
otherwise what's the point? It also seems like we shouldn't have to
go through nulling
18 dec 2007 kl. 13.26 skrev Grant Ingersoll:
I might be missing something here, but why do you clone?
Because the Token is changing and I am not saving all Tokens, just
the ones changed.
Aha!
The first thing to note is that TeeTokenFilter (TTF) is much
_slower_ in the case that all toke
On Dec 18, 2007, at 2:55 AM, Karl Wettin wrote:
17 dec 2007 kl. 05.40 skrev Grant Ingersoll:
a somewhat common case whereby two or more fields share a fair
number of common analysis steps.
Right.
For the smaller token counts, any performance difference is
negligible. However, even at
17 dec 2007 kl. 05.40 skrev Grant Ingersoll:
a somewhat common case whereby two or more fields share a fair
number of common analysis steps.
Right.
For the smaller token counts, any performance difference is
negligible. However, even at 500 tokens, one starts to see a
difference. The
For those who don't recall, TeeTokenFilter was added on https://issues.apache.org/jira/browse/LUCENE-1058
to handle what I would consider a somewhat common case whereby two
or more fields share a fair number of common analysis steps. For
instance, if one wanted a field that contained the pro
