1.2.1

1. Removed HuffmanLength.
Comment: Initialising of HuffmanTree was a bit inefficient because it was necessary to create a lot of HuffmanLength objects. After some consideration I realised that there is no need in them, so I replaced them with simple arrays. In result, performance in a scenario of decoding several files consequently should be better.

2. Rewritten DataWithPointer.
Comment: DataWithPointer was using CoreFoundation functions and CFBitVector to work with data. Initial thoughts were that this will allow to not load the entire file into the system memory. However, after reading a bit of the Internet, I realised that this behaviour is in fact defined by Data.ReadingOptions which are specified when the Data object is created. Then it became obvious to me that these shenanigans aren't necessary and I replaced them. Also, the note about ReadingOptions was added to README.

3. Added performance tests.
Comment: Now every Deflate or BZip2 test can be executed with performance testing. For this you need to add "-D PERF_TESTS" option to SWCompressionTests, e.g. xcodebuild -project SWCompression.xcodeproj -scheme SWCompression OTHER_SWIFT_FLAGS="-D PERF_TESTS" test. I've also added some results from these tests executed on my computer and Python script which can convert Xcode output into something human-readable.

1.2.0 (Huffman Tree)

Reimplemented Huffman Coding using a tree-like structure.
Comment: Previously all Huffman codes were stored in a list. Since we need to find each code in Huffman Table at least once and in the worst case scenario we need to check all codes to find the necessary one, one might say this could take O(n^2) amount of time, assuming we have n codes.

Now, when the codes are placed in a real Huffman Tree, theoretically, it should take O(n*log(n)) amount of time (because in the worst case we only need to go from root of the tree to its bottom instead of the entire list).

The price for this is that we need some preparatory work: building a tree. But some simplifications were made and this should not be a problem.

Overall, these changes should result in noticeable performance improvement (hopefully).

1.2.0 Test

Next (1.2.0) update will feature a lot of changes about how Huffman coding is processed. These changes should also improve performance.

1.1.2

• Fixed a WrongBlockLengths error when there was no actual error.
• Improved overall performance for Deflate.

By the way, there are also a couple of internal changes that are probably worth to mention:

1. Now git-lfs is used for storing the majority of test files. So if you would like to clone repository and run Xcode tests it might be necessary for you to run git lfs pull after git clone.
2. When Gzip files are being parsed sometimes incorrect value of mtime field from their headers could be read. Although, this value is internal (and, actually, is never used) and is not exposed to the users of framework you might be eager to know that from now on mtime is stored as four UInt8 numbers instead of one UInt64 (and I don't know why it was UInt64 and not UInt32).

1.1.1

• Fixed problems when building with Swift Package Manager.
• Added missing files to watchOS scheme.
• Every release on Github will now have an archive with pre-built framework.
• Added info about performance to README.

1.1.1 Test

This is a pre-release version of an upcoming 1.1.1 update which will feature some fixes for various build systems: Carthage and Swift Package Manager.

1.1.0 (BZip2)

• Added BZip2 decompression.
• Introduced subspecs with parts of functionality.
• Additional performance improvements.
• Fixed potential memory problems.
• Added a lot of (educational) comments for Deflate

1.0.3

Significant performance improvement.
Comment: This was done by writing a special class for acquiring bits from data. This class uses (hopefully) efficient CFBitVector object and its CFBitVectorGetBitAtIndex method. The results are great: up to 8.2 times faster than 1.0.1 and up to 3 times faster than 1.0.2. And yes, there is room for more improvements.

1.0.2

• Fixed a problem when there were significantly more amount of decompressed data than expected.

Comment: This was caused by string to data conversion. To fix this, intermediate results are now stored directly in Data object.

• Performance improvement.

Comment: This was achieved by decreasing amount of times when input data are read during search of a next symbol in Huffman Table. More performance improvements are ahead.

1.0.1

• Sometimes in bit shift calculations this shift can become greater than or equal 16 and this was causing crashes. It was fixed.
• There was a typo which also was causing crashes.
• Finally, sometimes two bytes were not enough for calculating next symbol and this was also a reason for a crash.