Attempt to estimate the minimum required buffer length when initializing StreamsSequenceStream instances
#9925
Conversation
…izing `StreamsSequenceStream` instances For most other `DecodeStream` based streams, we'll attempt to estimate the minimum `buffer` length based on the raw stream data. The purpose of this is to avoid having to unnecessarily re-size the `buffer`, thus reducing the number of *intermediate* allocations necessary when decoding the stream data. However, currently no such optimization is attempted for `StreamsSequenceStream`, and given that they can often be quite large that seems unfortunate. To improve this, at least somewhat, this patch utilizes the raw sizes of the `StreamsSequenceStream` sub-streams to estimate the minimum required `buffer` length. Most likely this patch won't have a huge effect on memory consumption, however for pathological cases it should help reduce peak memory usage slightly. One example is the PDF file in issue 2813, where currently the `StreamsSequenceStream` instances would grow their `buffer`s as `2 MiB -> 4 MiB -> 8 MiB -> 16 MiB -> 32 MiB`. With this patch, the same stream `buffers`s grow as `8 MiB -> 16 MiB -> 32 MiB`, thus avoiding a total of `12 MiB` of *intermediate* allocations (since there's two `StreamsSequenceStream` used, for rendering/text-extraction).
|
/botio-windows test |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/c1b60031b515e90/output.txt |
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/c1b60031b515e90/output.txt Total script time: 26.48 mins
|
|
/botio-linux test |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/0a57612ad95fb08/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/0a57612ad95fb08/output.txt Total script time: 19.47 mins
|
|
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/eb6fc56209447cb/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/eb6fc56209447cb/output.txt Total script time: 2.89 mins Published |
|
Nice find! |
For most other
DecodeStreambased streams, we'll attempt to estimate the minimumbufferlength based on the raw stream data. The purpose of this is to avoid having to unnecessarily re-size thebuffer, thus reducing the number of intermediate allocations necessary when decoding the stream data.However, currently no such optimization is attempted for
StreamsSequenceStream, and given that they can often be quite large that seems unfortunate. To improve this, at least somewhat, this patch utilizes the raw sizes of theStreamsSequenceStreamsub-streams to estimate the minimum requiredbufferlength.Most likely this patch won't have a huge effect on memory consumption, however for pathological cases it should help reduce peak memory usage slightly.
One example is the PDF file in issue #2813, where currently the
StreamsSequenceStreaminstances would grow theirbuffers as2 MiB -> 4 MiB -> 8 MiB -> 16 MiB -> 32 MiB. With this patch, the same streambufferss grow as8 MiB -> 16 MiB -> 32 MiB, thus avoiding a total of12 MiBof intermediate allocations (since there's twoStreamsSequenceStreamused, for rendering/text-extraction).