[RFC] KnitData.read_records_iter() returns records out of order

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Ellerman wrote:
> On 6/26/06, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>> Michael Ellerman wrote:

>> My preference, in terms of cleanliness, would be to have the Transport
>> take care of requesting the records in optimal order and returning them
>> in the requested order.
> 
> I disagree, although that might be clean, it means we end up doing
> work we don't need to. I'd rather push the sorting requirement up the
> stack, so that we delay sorting as long as possible, and some callers
> won't require sorting at all.

It would be possible to structure readv so that it always returned the
records in the requested order, but didn't store them in a map unless
the requested order differed from the optimal order.

> So we document the fact that readv() may return records out of order,
> and so on up the stack. We can write an OutOfOrderLocalTransport that
> returns everything in random orders for testing.
> 
>> Callers like _get_record_map must store all the records in a dict
>> anyway, so they'll have no memory savings.
> 
> Sure, but that's a seperate performance/memory tradeoff that we can
> decide to make.

We could also decide to make iter_lines_added_or_present_in_versions
batch its requests.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEn8re0F+nu1YWqI0RAm3uAJwIe7cxUABcqW7ydpMKxz6VWi/c2gCdFhxr
MLRwFt8nqgO97f6QAS0TFnM=
=Y/+Y
-----END PGP SIGNATURE-----