How is chunkBy supposed to behave on copy

[H. S. Teoh]

On Wed, Mar 18, 2020 at 01:06:02PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 3/18/20 12:37 PM, H. S. Teoh wrote:
[...]
> > That's up for debate, but yes, the whole point of the reference
> > counting thing is to avoid traversing a forward range twice when
> > iterating over subranges.
[...]
> Ugh, I think this is way overkill in most cases, and depends heavily
> on where the performance hit is.
> 
> Not only that, but you are only seeing a benefit if you iterate a
> chunk completely (I think).

Yeah probably.


> For instance, an array has nearly zero cost to iterate elements, but
> the predicate for checking the chunking is probably way more
> expensive. The algorithm would be nicer if you simply iterated the
> array until you found the boundary, and then returned a slice as the
> element. Only one iteration through everything necessary (you
> pre-calculate the "next" range).

We *could* just detect hasSlicing!R and switch to an alternative
implementation that doesn't need to jump through all of those
refcounting hoops.


> In other cases, iterating the elements is going to be expensive, so
> you don't want to do that twice if possible.
> 
> I think a good solution might be to provide different versions of the
> function or an enum designating what mechanism to prefer (e.g.
> IterationPolicy.MinimizePopfront or
> IterationPolicy.MinimizePredicateEval).
[...]

It sounds like a good idea, but these days I'm wary of proliferating
these implementation-detail-based parameters.  They're a pain to write,
a pain to use, and a pain to maintain, and once you have the option
you're committed to supporting it even if one day you invent a better
algorithm that completely changes the implementation.

I much rather detect hasSlicing on the incoming range, and switching to
a better implementation.


T

-- 
INTEL = Only half of "intelligence".