to fix but this class is way too much complicated for me, so here my
attempt to repair my mistake.
> InstantiatedIndex : TermFreqVector is missing
> -
>
> Key: LUCENE-1964
> URL: https://issues.apache.
[
https://issues.apache.org/jira/browse/LUCENE-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Causse updated LUCENE-1964:
-
Attachment: term-vector-fix.patch
Fix the TermVector storing problem.
> InstantiatedIn
InstantiatedIndex : TermFreqVector is missing
-
Key: LUCENE-1964
URL: https://issues.apache.org/jira/browse/LUCENE-1964
Project: Lucene - Java
Issue Type: Bug
Components: contrib
x27;t had time to look at this. Looks like it's completed, great
work!
> InstantiatedIndex supports non-optimized IndexReaders
> -
>
> Key: LUCENE-1578
> URL: https://issues.apach
[
https://issues.apache.org/jira/browse/LUCENE-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin resolved LUCENE-1578.
-
Resolution: Fixed
comitted
> InstantiatedIndex supports non-optimized IndexRead
out? It seems to work fine for me and I plan
to pop it in the trunk in a few days. I think I'll have to add a warning of
some kind in runtime though as it could slow down the index a bit if the reader
is way fragmented.
> InstantiatedIndex supports non-optimized
[
https://issues.apache.org/jira/browse/LUCENE-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin reassigned LUCENE-1578:
---
Assignee: Karl Wettin
> InstantiatedIndex supports non-optimized IndexRead
Hi Ravichandra,
this is a question better fitted the java-users maillinglist. On this
list we talk about the development of the Lucene API rather than how
to use it.
To answer your question, there is no simple formula that says how much
RAM an InstantiatedIndex will consume given the
Hi
So far I am using RAMDirectory for my indexes. To meet the SLA of our
project, i thought of using InstantiatedIndex. But when I used that, i am
not able to get any out put from that and its throwing out of memory error.
What is the ratio between Index size and memory size, when using
readers in the
constructor.
> InstantiatedIndex supports non-optimized IndexReaders
> -
>
> Key: LUCENE-1578
> URL: https://issues.apache.org/jira/browse/LUCENE-1578
> Project: Lucene - Jav
28 mar 2009 kl. 01.21 skrev Jason Rutherglen:
I'm thinking InstantiatedIndex needs to implement either clone of
all the index data or needs to be able to accept a non-optimized
reader, or both. I forget what the obstacles are to implementing
the non-optimized reader option? D
InstantiatedIndex supports non-optimized IndexReaders
-
Key: LUCENE-1578
URL: https://issues.apache.org/jira/browse/LUCENE-1578
Project: Lucene - Java
Issue Type: Improvement
Hi Karl,
I'm thinking InstantiatedIndex needs to implement either clone of all the
index data or needs to be able to accept a non-optimized reader, or both. I
forget what the obstacles are to implementing the non-optimized reader
option? Do you think there are advantages or disadvantages
Once I added support for InstantiatedIndex in the benchmarker. I had to
refactor the benchmarker so it used a new factory class rather than a
Directory to create readers and writers. The writer had to be a clone of
IndexWriter (or atleast contained the methods used by the jobs) that
decorated
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-550.
Resolution: Fixed
Committed revision 636745. Thanks Karl!
> InstantiatedIndex - fas
PNG and then scaled to fit 1024x768. Also
softscaled in package.html, but linked to when clicked on.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://is
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: classdiagram.jpg)
> InstantiatedIndex - faster but memory consuming in
sticky enough for instantiated/docs/classdiagram.jpg.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
>
.I'll commit
tomorrow, pending any more feedback.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
&
arrays, which I wrote and wish
to donate to the ASF (for the Lucene project or any other purpose), following
Karl Wettin's request.
This code was initially published on my blog :
http://ochafik.free.fr/blog/?p=106
Have fun with it !
--
Olivier Chafik
> InstantiatedIndex - faster but memory c
t we may not see it
for a good long time, depending on their commit/release needs.
OK. Once we get the legal piece resolved, I am going to commit.
-Grant
> InstantiatedIndex - faster but memory consuming index
> -
>
>
is a new patch?
{quote}
Not anytime soon. They are only ideas that could make it a bit less ad hoc. But
I'm actually quite happy with the way it works now. The code has sucessfully
been used in a handful of commercial projects.
> InstantiatedIndex - faster but memor
arta Commons? Without him actually doing it,
I don't know that it is good enough legally to accept it.
Also, is your last comment such that you think there is a new patch?
> InstantiatedIndex - faster but memory con
and came to the conclution that
InstantiatedIndexWriter is depricated code, that it is enough one can construct
InstantiatedIndex using an optimized IndexReader. This makes all
InstantiatedIndexes immutable. That makes the no-locks caveat to go away.
Also, it is a hassle to make sure
n, the
variable pivot is most welcome.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
> P
? He contributed the code personally or you got it from
him? In other words, do you have the authority to assign the ASF copyright for
said code?
FYI, the patch applies clean and compiles. I still have some benchmarking to
do, but would like to commit.
> InstantiatedIndex - faster but mem
implementation delivers search results up to a 100 times faster than the
file-centric RAMDirectory at the cost of greater RAM consumption.
Performance seems to be a little bit better than log2n (binary search). No real
data on that, just my eyes.
Populated with a single document InstantiatedIndex
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: LUCENE-550_20071019_no_core_changes.txt)
> InstantiatedIndex - faster
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: LUCENE-550_20071017_no_core_changes.txt)
> InstantiatedIndex - faster
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: LUCENE-550_20071008_no_core_changes.txt)
> InstantiatedIndex - faster
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: LUCENE-550_20070817_no_core_changes.txt)
> InstantiatedIndex - faster
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: LUCENE-550_20070928_no_core_changes.txt)
> InstantiatedIndex - faster
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: LUCENE-550_20070808_no_core_changes.txt)
> InstantiatedIndex - faster
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: LUCENE-550_20070804_no_core_changes.txt)
> InstantiatedIndex - faster
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: lucene-550.jpg)
> InstantiatedIndex - faster but memory consuming in
Array.binarySearch is 20% faster than
Collections.binarySearch.
* Ad hoc binarySearch using variable pivot increase speed of TermDocs.skipTo
20%-400%, courtesy of Olivier Chafik.
* Default InstantiatedWriter.mergeFactor changed from 1 to 2500 ;-)
> InstantiatedIndex - faster but mem
) optimization, initial seek now jit-call away given
the term exists, rather than using binary search.
* A handful of minor optimizations
* IndexReader.version() mimics Segment-dito
> InstantiatedIndex - faster but memory consuming in
-mapper term vector methods returns null rather than
throwing NPE when term vector is not available.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.
documentation.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
> Project: Lucene - Java
>
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530875
]
Karl Wettin commented on LUCENE-550:
Oups, the patch is of course granted ASF licence.
> InstantiatedIn
dull boy",
Field.Store.NO));
d.add(new Field("f", " All work and no play makes Jack a dull boy",
Field.Store.YES, Field.Index.NO_NORMS, Field.TermVector.NO));
{code}
Would this be considered an invalid document? Should there be a term vector or
not? Or perhaps just te
e as well, and put a link to
it in the javadocs as well.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
>
if (field.tokenStreamValue() != null) {
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
>
compared term by
term, etc. (vectors, etc.)
I would like to see payloads tested as well.
I also think you need a package level javadoc that explains the use cases for
this and the basics of using it.
Also, I notice the caveat about no locking (in the javadocs for
InstantiatedIndex) and I notice a
phrase (term position) problem
turned out to be the constructor InstantiatedIndex(IndexReader) that had a bug,
ending up with a index not equal to one created via InstantiatedIndexWriter.
I also did a bunch of tests on how much it would speed up by replacing the
binary searches over lists with hash
earch(IndexSearcher.java:146)
at org.apache.lucene.search.Searcher.search(Searcher.java:118)
at org.apache.lucene.search.Searcher.search(Searcher.java:97)
> InstantiatedIndex - faster but memory consuming index
> -
>
>
you figure this out?
Please don't. I'm just thinking really lound.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apach
?
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
> Project: Lucene - Java
> Issue Type: New Feature
t binary searches are placed in the IndexWriter, and I honestly don't care
too much about make that part faster if it slows down searching or makes it hog
more RAM.
> InstantiatedIndex - faster but memory consuming index
> -
>
&g
TermEnum, and a HashMap would make it much faster, especially as the index
grows. Might speed things up alot.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
>
your patch
gets in before anyone changes it, the onus is on that person to make sure the
change is functional, so I would think you are fine to assume the current
payload is fixed for the time being.
> InstantiatedIndex - faster but memory consuming in
ts are virtually non-existent
>
> It could also use some documentation, especially on the how and why of the
> InstantiatedIndex.
I'll come up with some stuff asap.
About tests, the new patch is more or less a redection of the previous patch.
The latter contains more or less all test
at this point for me:
1. No build file
2. Tests are virtually non-existent
It could also use some documentation, especially on the how and why of the
InstantiatedIndex.
Cheers,
Grant
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-550:
--
Assignee: Grant Ingersoll (was: Karl Wettin)
> InstantiatedIndex - faster but mem
of InstantiatedIndex, the
results of my "last attempt" thread:
http://www.nabble.com/Last-attempt-tf4153815.html
It requires no changes to the Lucene core but hogs a bit more RAM and probably
depends on your JIT to avoid wasting CPU. So prior required definalization and
general
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: HitCollectionBench.jpg)
> InstantiatedIndex - faster but memory consum
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: HitCollectionBench.jpg
x/y axis names updates
> InstantiatedIndex - faster but mem
ocuments)
is fairly busy, on average one query every 10ms 24/7. Peeks at one every 2ms.
On the single machine setup with 4GB and Solaris the CPU went from 90% busy to
90% idle when switching from RAMDirectory to InstantiatedIndex. I can at this
point not say if this is due to bad use of Lucene and
elooking at the UML diagram) : Unless you allow to put POJO objects in
a Document ?
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: HitCollectionBench.jpg)
> InstantiatedIndex - faster but memory consum
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: HitCollectionBench.jpg
made graph more readable
> InstantiatedIndex - faster but mem
InstantiatedIndex,
RAMDirectory and FSDirectory.
In essence, there is no great win in pure search time when there are more than
7000 documents. However, retreiving documents is still not associate with any
cost what so ever, so in a 25 sized index that use Lucene for persistency
of fields, I still see a
nyhow, for the running tasks to share a reader, the alg part of the .alg file
should have something like this:
OpenReader
ReaderTaskA
ReaderTaskB
ReaderYaskC
CloseReader
This way all three tasks would share the same, already open, reader.
> InstantiatedIndex - faster but memory c
poor results compared to my own test and live enviroment
stats. At query time I expected maximum 1/6th time spent in InstantiatedIndex
than RAMDirectory, but it turns out that in the benchmarker the speed is almost
the same as RAMDirectory. Retrieving documents is only 1/5th of the speed
rather
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: trunk.diff.bz2
Patched contrib/benchmark to support InstantiatedIndex.
Fixed a bug with
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: didyoumean.jpg)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: trunk.diff.bz2
Removed the dependencies to LUCENE-626.
> InstantiatedIndex - faster
suggester much faster.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
> Project: Lucene - Jav
ld be solved with bootstrapping. Will mess with that later.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
&
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: trunk.diff.bz2
Support for deleteDocuments in IndexWriterInterface, InstantiatedIndex
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: trunk.diff.bz2
Added lots of documentation
> InstantiatedIndex - faster but mem
http://ginandtonique.org/~kalle/javadocs/didyoumean/org/apache/lucene/search/didyoumean/package-summary.html
(Sorry for flooding..)
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
>
ter().put(new
SecondLevelTokenPhraseSuggester(ngramSuggester, aprioriField, false,
maxSuggestionsPerToken, new WhitespaceAnalyzer(), aprioriIndex), 1d);
}
Persistence and memory usage.
By default the dictionary is soft referenced,
meaning it will consume as much memory it can get,
and if some o
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Comment: was deleted
> InstantiatedIndex - faster but memory consuming in
t maxSuggestionsPerToken = 3;
// add ngram suggester wrapped in a single token phrase suggester as
second level suggester.
suggestionFacade.getDictionary().getPrioritesBySecondLevelSuggester().put(new
SecondLevelTokenPhraseSuggester(ngramSuggester, aprioriField, false,
maxSugg
comments
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
> Project: Lucene - Java
> Is
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: trunk.diff.bz2
Updated spell checker code
> InstantiatedIndex - faster but mem
parameter indexWriter
*/
public void writeToIndex(IndexWriterInterface indexWriter) throws IOException
{
{code}
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
>
.
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
> Project: Lucene - Java
> Is
like the index in a
specific state as represented by a reader.
*
* @param sourceIndexReader the source index this new instantiated index will
be copied from.
* @throws IOException if the source index is not optimized, or when accesing
the source.
*/
public InstantiatedIndex
this index. Always fresh. */
public IndexReader getReader() throws IOException {
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.
Or should I perhaps use the lock Directory:s use?
(And that class diagram is of course granted for ASF, my misstake.)
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
>
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: issue550.jpg)
> InstantiatedIndex - faster but memory consuming in
uxf-file for umlet)
> InstantiatedIndex - faster but memory consuming index
> -
>
> Key: LUCENE-550
> URL: https://issues.apache.org/jira/browse/LUCENE-550
> Project: Lucene - Java
>
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff.bz2)
> InstantiatedIndex - faster but memory consuming in
[
https://issues.apache.org/jira/browse/LUCENE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-550:
---
Attachment: (was: trunk.diff)
> InstantiatedIndex - faster but memory consuming in
rsion:
org.apache.lucene.index.facade.IndexModifier(myIndex, analyzer, create)
where all reader/writer creation is myIndex.indexReaderFactory() and
indexWriterFactory();
Makes the Notifiable code a bit simpler.
> InstantiatedIndex - faster but memory consumi
alized that all of the tests in
> contrib/instantiated/src/test/java/org/apache/lucene/
> instantiated/assimilated/ are duplicates of tests from the core with a few
> line changes
> so they use an InstantiatedIndex to get a reader/writer/seracher etc.
This is not a bad idea at all, but
1 - 100 of 128 matches
Mail list logo
