You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Marvin Humphrey <ma...@rectangular.com> on 2013/09/18 01:43:45 UTC

[lucy-dev] DH_Get_Entry allocating on each iter

On Mon, Aug 26, 2013 at 3:51 PM,  <nw...@apache.org> wrote:
> Change DH_Get_Entry semantics
>
> Now DH_Get_Entry must be called after DH_Next and it returns an incref'd
> CharBuf. Eliminates a couple of calls to CB_Mimic.

> Project: http://git-wip-us.apache.org/repos/asf/lucy/repo
> Commit: http://git-wip-us.apache.org/repos/asf/lucy/commit/5ef340d4
> Tree: http://git-wip-us.apache.org/repos/asf/lucy/tree/5ef340d4
> Diff: http://git-wip-us.apache.org/repos/asf/lucy/diff/5ef340d4

The initial design tried to avoid the cost of string allocation on each
iteration, but maybe in this case allocation is negligible in comparison to
the cost of the system call?  Is this worth microbenchmarking just to see?

Marvin Humphrey

Re: [lucy-dev] DH_Get_Entry allocating on each iter

Posted by Nick Wellnhofer <we...@aevum.de>.
On 18/09/2013 01:43, Marvin Humphrey wrote:
> On Mon, Aug 26, 2013 at 3:51 PM,  <nw...@apache.org> wrote:
>> Change DH_Get_Entry semantics
>>
>> Now DH_Get_Entry must be called after DH_Next and it returns an incref'd
>> CharBuf. Eliminates a couple of calls to CB_Mimic.
>
>> Project: http://git-wip-us.apache.org/repos/asf/lucy/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/lucy/commit/5ef340d4
>> Tree: http://git-wip-us.apache.org/repos/asf/lucy/tree/5ef340d4
>> Diff: http://git-wip-us.apache.org/repos/asf/lucy/diff/5ef340d4
>
> The initial design tried to avoid the cost of string allocation on each
> iteration, but maybe in this case allocation is negligible in comparison to
> the cost of the system call?  Is this worth microbenchmarking just to see?

This probably depends much on the OS and filesystem. Even if the cost of 
the additional allocations is visible, it don't think it's a problem. 
Reading lots of directory entries in performance-critical code should be 
unusual.

Nick