##// END OF EJS Templates
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
Gregory Szorc -
r39596:84bf6ded default
Show More
Name Size Modified Last Commit Author
/ mercurial / cext
__init__.py Loading ...
base85.c Loading ...
bdiff.c Loading ...
charencode.c Loading ...
charencode.h Loading ...
dirs.c Loading ...
manifest.c Loading ...
mpatch.c Loading ...
osutil.c Loading ...
parsers.c Loading ...
pathencode.c Loading ...
revlog.c Loading ...
util.h Loading ...