view tests/test-issue619.t @ 39560:84bf6ded9317

wireprotoframing: buffer emitted data to reduce frame count

An upcoming commit introduces a wire protocol command that can emit
hundreds of thousands of small objects. Without a buffering layer,
we would emit a single, small frame for every object. Performance
profiling revealed this to be a source of significant overhead for
both client and server.

This commit introduces a very crude buffering layer so that we emit
fewer, bigger frames in such a scenario. This code will likely get
rewritten in the future to be part of the streams API, as we'll
need a similar strategy for compressing data. I don't want to think
about it too much at the moment though.

server
before: user 32.500+0.000 sys 1.160+0.000
after:  user 20.230+0.010 sys 0.180+0.000

client
before: user 133.400+0.000 sys 93.120+0.000
after:  user  68.370+0.000 sys 32.950+0.000

This appears to indicate we have significant overhead in the frame
processing code on both client and server. It might be worth profiling
that at some point...

Differential Revision: https://phab.mercurial-scm.org/D4473

https://bz.mercurial-scm.org/619

  $ hg init
  $ echo a > a
  $ hg ci -Ama
  adding a

  $ echo b > b
  $ hg branch b
  marked working directory as branch b
  (branches are permanent and global, did you want a bookmark?)
  $ hg ci -Amb
  adding b

  $ hg co -C 0
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved

Fast-forward:

  $ hg merge b
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)
  $ hg ci -Ammerge

Bogus fast-forward should fail:

  $ hg merge b
  abort: merging with a working directory ancestor has no effect
  [255]

Even with strange revset (issue4465)

  $ hg merge ::.
  abort: merging with a working directory ancestor has no effect
  [255]