BlockCompressorStream<\/code> and XPressStream<\/code>.<\/p>\n\nBlockCompressorStream<\/code> \u2013 Reads a block header containing the compressed and decompressed size and holds the block, max 65K, in memory to return to the next stream.<\/li>\nXPressStream<\/code> \u2013 Reads a compressed byte stream and decompresses it on the fly using the XPress decompression algorithm. The general algorithm is to read a byte or two, determine the \u201ccodeword\u201d, then use that to inflate by either adding the next few bytes or copying them from the already decompressed stream.<\/li>\n<\/ul>\nThe general structure of the code looks like so:\n![\"XPress](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2022\/04\/Stream.png\")
<\/a><\/p>\nDigging for performance<\/h2>\n
To get a general idea of the performance I first started with the CPU Usage tool<\/a>, I was curious how long it would take and what part of the algorithm is the hot spot. While I could launch a Visual Studio patch with my code, I opted for an easier route that scoped what I was profiling to just my decompression algorithm. During development I created a bunch of unit tests to verify the compression. One such test was to take a large, compressed file and decompress it to a known file that I can then check the hashes against. I wrote a simple console application in my solution that instantiates the unit test class and then just invokes the unit test, allowing me to reuse assets and quickly profile things as the \u201cstartup project\u201d. After running the CPU Usage tool against this exe, I had the following:<\/p>\n![\"CPU](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2022\/04\/Picture1.png\")
<\/a><\/p>\nThis is what I expected to see since XPressStream.ReadBlock()<\/code> is doing the actual decompression which is good, my mental model of what my code does matches reality.<\/p>\nWhat is a bit odd is that less than a third of the time is spent in the function (self), the rest of the time is in child functions (total – self). Looking at the CPU tool\u2019s new flame chart I see most of the time seems to be spent reading in UInt16<\/code>.<\/p>\n![\"Flame](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2022\/04\/Picture2.png\")
<\/a><\/p>\nI assumed reading in the data would take some time, but I didn\u2019t expect it to take 2\/3 of my algorithms time<\/strong>. Peeking at the BlockCompressor.Read<\/code> I can see it spending most of the time reading the stream which got me thinking maybe I\u2019m not buffering enough. Looking at where I construct the BufferedStream, sure enough I\u2019m using the default buffer size which normally is fine, but I know that my blocks can never be more than 65,536<\/code>.<\/p>\n\r\npublic BlockCompressorStream(Stream stream)\r\n{\r\n \/\/ We add a buffer stream around the stream to handle the buffering for us\r\n this.stream = new BufferedStream(stream);\r\n\r\n if (!this.ReadHeader())\r\n {\r\n throw new InvalidDataException();\r\n }\r\n}\r\n<\/pre>\nI could buffer that much by default though it seems it bit much, instead I chose to buffer half as much 32,768<\/code>. If tuning this was super important, I would profile the code with various sizes to determine the correct tradeoff of memory size to performance, but I\u2019m not overly concerned and instead will just leave a comment for the next dev to hit this code. Rerunning the CPU Usage, I find that I didn\u2019t quite double performance, but I got pretty close.<\/p>\n![\"Improved](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2022\/04\/Picture4.png\")
<\/a><\/p>\nPoking around a little more I don\u2019t immediately notice anything that is jumping out. Since we are using a buffered stream and I don\u2019t allocate anything in the algorithm I figured I should verify my allocations are at a steady state. To do that I ran the .NET Object Allocation profiler<\/a> on the test case and got the following:<\/p>\n![\"Allocation](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2022\/04\/Picture5.png\")
<\/a><\/p>\nImmediately I noticed the two GCs which I really didn\u2019t expect. Maybe the BufferedStream<\/code> allocation put us over budget for 1 GC but 2 seems a bit suspect. Looking at the collections tab I actually have 3 GCs, and they are due to \u201cAllocSmall\u201d indicating we are allocating a bunch of small objects and trying to collect them:<\/p>\n![\"Top](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2022\/04\/Picture6.png\")
<\/a><\/p>\nWhat is interesting is the top type we are allocating is a byte array of length 1, which is almost never correct. Jumping over to allocations I can confirm I\u2019m actually allocating over 200K byte[1]<\/code> arrays which is terrible. Looking at the backtrace it is coming from Stream.ReadByte<\/code>, which is the default implementation my BlockCompressorStream<\/code> is using.<\/p>\n![\"Backtrace](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2022\/04\/Picture7.png\")
<\/a><\/p>\nNavigating to source through the context menu I see the code and I\u2019m horrified to realize that yep, it is allocating a byte[1]<\/code> so it can call into Read(byte[], int, int)<\/code>. Since BufferedStream<\/code> is holding the buffered data in memory it should be able to return the byte from its current location. Checking on ReferenceSource I can confirm it is doing just that: bufferedstream.cs (microsoft.com)<\/a><\/p>\n![\"Batman](\"https:\/\/devblogs.microsoft.com\/visualstudio\/wp-content\/uploads\/sites\/4\/2022\/04\/Allocating-300x290.jpg\")
<\/a><\/p>\nOverriding Stream.ReadByte<\/code> in my BlockCompressorStream<\/code> and using the BufferedStream<\/code> implementation I\u2019m now in a much better allocation situation:<\/p>\n