- Use '/' key to quickly access this field.
- Enter a name of repository, or repository group for quick search.
- Prefix query to allow special search:
user:admin, to search for usernames, always global
user_group:devops, to search for user groups, always global
pr:303, to search for pull request number, title, or description, always global
commit:efced4, to search for commits, scoped to repositories or groups
file:models.py, to search for file paths, scoped to repositories or groups
For advanced full text search visit: repository search
wireprotoframing: buffer emitted data to reduce frame count...
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