Re: [Monotone-devel] oprofile data for mtn 0.37.

[Jack Lloyd]

On Thu, Mar 13, 2008 at 01:09:34PM -0400, Zack Weinberg wrote:
> This is worrisome; a netsync server on a large repository might be
> doing thousands of hex encoding operations per revision transferred,
> which would add up fast.  And it's precisely that  operation we want
> to speed up by avoiding creation of new Pipes per operation.
> 
> (yes, we are trying to reduce the incidence of those, but ...)

Agree. I am pondering alternatives.

> 
> >  The message number can (and probably should) be changed to a long
> >  long, though also the underlying issue that Pipe should detect/signal
> >  this condition needs fixing.
> 
> Why not recycle message numbers once completely consumed?

This would actually work in many cases, BUT would probably fail
horribly if the app doesn't actually read out all of the message data.
For instance

  write one message M1, dont't read it back
  write 2^32-1 messages, reading each one back
  write one message M2

Now if you ask for the contents of message 0, you get M1 || M2.

(However in the cases where it can work without problems, it should)

-Jack