Mojo EDK: Periodically trim the incoming message buffer |
|||
Issue descriptionThe EDK's Channel manages a read buffer for receiving incoming IPC message data. This buffer grows dynamically as needed and its capacity is recycled ASAP (usually after every message, in practice). If a large message arrives the buffer will grow to accommodate it, but we never shrink the buffer back down in the absence of further large messages. We should do this periodically shrink it back down periodically to avoid wasting lots of memory, particularly on low-end devices.
,
Mar 11 2016
,
Mar 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3e0d30405b64ff0011aa347e9ecbe891e9e2ec66 commit 3e0d30405b64ff0011aa347e9ecbe891e9e2ec66 Author: rockot <rockot@chromium.org> Date: Tue Mar 29 23:34:02 2016 [mojo-edk] Trim read buffer to keep its size down Shrinks Channel's read buffer back down to the maximum unused capacity any time its contents have been fully discarded. This prevents us from permanently wasting memory after a large IPC is transmitted. Based on work detailed in issue 529940 , the max unused capacity has also been reduced from 256 kB down to 64 kB. In practice we rarely transmit messages larger than this, so the performance impact of these extra allocations should be negligible. BUG= 593731 , 500019 R=amistry@chromium.org Review URL: https://codereview.chromium.org/1835933002 Cr-Commit-Position: refs/heads/master@{#383862} [modify] https://crrev.com/3e0d30405b64ff0011aa347e9ecbe891e9e2ec66/mojo/edk/system/channel.cc
,
Mar 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3e0d30405b64ff0011aa347e9ecbe891e9e2ec66 commit 3e0d30405b64ff0011aa347e9ecbe891e9e2ec66 Author: rockot <rockot@chromium.org> Date: Tue Mar 29 23:34:02 2016 [mojo-edk] Trim read buffer to keep its size down Shrinks Channel's read buffer back down to the maximum unused capacity any time its contents have been fully discarded. This prevents us from permanently wasting memory after a large IPC is transmitted. Based on work detailed in issue 529940 , the max unused capacity has also been reduced from 256 kB down to 64 kB. In practice we rarely transmit messages larger than this, so the performance impact of these extra allocations should be negligible. BUG= 593731 , 500019 R=amistry@chromium.org Review URL: https://codereview.chromium.org/1835933002 Cr-Commit-Position: refs/heads/master@{#383862} [modify] https://crrev.com/3e0d30405b64ff0011aa347e9ecbe891e9e2ec66/mojo/edk/system/channel.cc
,
Mar 30 2016
|
|||
►
Sign in to add a comment |
|||
Comment 1 by roc...@chromium.org
, Mar 10 2016