the problem is really simpler to solve actually.
Look at the comments in the code, it tells you why it is this way:
// NOTE: we could have one buffer, but various consumers (e.g.
FieldComparatorSource)
// assume "they" own the bytes after calling this!
That is what we should fix. There is no need to make bulk APIs or even
change the public api in any way (other than javadocs).
We just move the clone'ing out of the codec, and require the consumer to do
it, same as termsenum or other apis. The codec part is extremely simple
here, its even the way i had it initially.
But at the time (and even still now) this comes with some risk of bugs. So
initially I removed the reuse and went with a more conservative approach to
start with.
On Fri, Jan 10, 2014 at 2:36 PM, Mikhail Khludnev <
[email protected]> wrote:
> Adrian,
>
> Please find bulkGet() scratch. It's ugly copy-paste, just reuses ByteRef
> that provides 10% gain.
> ...
> bulkGet took:101630 ms
> ...
> get took:114422 ms
>
>
>
> On Fri, Jan 10, 2014 at 8:58 PM, Adrien Grand <[email protected]> wrote:
>
>> I don't think we should add such a method. Doc values are commonly
>> read from collectors, so why do we need a method that works on top of
>> a DocIdSetIterator? I'm also curious how specialized implementations
>> could make this method faster than the default implementation?
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
> Principal Engineer,
> Grid Dynamics
>
> <http://www.griddynamics.com>
> <[email protected]>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
