Not sure when you would need an ExecutorService (why do you think you
need one?) but here are some links for the other two:
http://blog.mikemccandless.com/2011/11/near-real-time-readers-with-lucenes.html
http://blog.mikemccandless.com/2011/09/lucenes-searchermanager-simplifies.html
https://github.
yes and no!
google is not only the search engine ...
> Just curious about that. Any thoughts?
>
> Thanks
-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.ap
Hi Uwe,
> Die, Maven, die :-)
Well, I for myself have a love-hate-relationship to maven: its simple
and works nice for deps management. also others can set it up quickly
and IDE support is nice. But sometimes it does a bit too much
(unexpected ;)) or is too complicated to customize.
> (I assum
> I mean my benchmarks show up
> to 300% improvement with 4.x versus older versions so something is
> weird ie. non-realistic here or there is a bug so lets figure this
> out. Can you profile you app and see if you find something suspicious?
> I'll try now and report back.
It seems to be largely
Hi Simon,
answers below.
>> It does not seem to be an 'IO related issue' because using RAMDirectory
>> results in the same times.
>> And indexing via Luc4 with only one thread shouldn't be slower than 3.5 (?)
> it could be since we use a different term dictionary impl which is
> more expensive in
more segments to disk than 3.5
> so what you are seeing is likely a merge that is still trying to merge
> small segments. can you rerun and only measure the time until the last
> commit finishes (not the close)
>
> one more thing, you are indexing always the more or less same document
>
Hi,
I recently switched an experimental project from Lucene 3.5 to 4.0 from
6th Dec 2011
and my indexing time increased by nearly 20% on my local machine*.
It seems to me that two simple StringField's could cause this slow down:
Field uIdField = new Field("_uid", "" + id, StringField.TYPE_STORED);
