On 18/09/2013 01:43, Marvin Humphrey wrote:
On Mon, Aug 26, 2013 at 3:51 PM, <[email protected]> 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
