Keeping things in memory and not re-reading them from disk is what
really sang the song for us. Even if the initial read-in was more
costly due to decompression, the long-term amortized benefit of not
re-reading would still be a big winner.


On Sat, Jan 25, 2014 at 5:37 PM, Robert Muir <[email protected]> wrote:
> well the Directory layer likely isnt what probably makes DirectPF faster for
> you. Its probably the fact it does no compression at all...
>
>
> On Sat, Jan 25, 2014 at 5:34 PM, Benson Margulies <[email protected]>
> wrote:
>>
>> On Sat, Jan 25, 2014 at 5:09 PM, Robert Muir <[email protected]> wrote:
>> > That would be Directory :)
>>
>> Oh,  how embarrassing. I could have written a custom directory to begin
>> with.
>>
>> Would a Directory class for this purpose be an interesting patch, in
>> that case? I'm not discontented about building a Directory into our
>> application, but it seems like I might not be the only person to find
>> this useful.
>>
>> >
>> >
>> > On Sat, Jan 25, 2014 at 5:03 PM, Benson Margulies
>> > <[email protected]>
>> > wrote:
>> >>
>> >> I've had very gratifying results using the DirectPostingFormat to
>> >> speed up queries when I had a read-only index with plenty of memory.
>> >> The only downside was the need to specify it within the Codec, and
>> >> thus write it into the index.
>> >>
>> >> Ever since, I've wondered if we could change things to introduce the
>> >> same goodness without building it into the codec.
>> >>
>> >> Very roughly, I'm imagining an option in the IndexReader to provide an
>> >> object that can surround the codec that is called for in the stored
>> >> format.
>> >>
>> >> Is this an old question? Is it worth sketching a patch?
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [email protected]
>> >> For additional commands, e-mail: [email protected]
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to