Hi,

I am the author of LibDeflate. I don't have much time playing the game recently.
It seems you're one of the first people who use LibDeflate in your addon.
This addon is very new. Even if I have made lots of efforts to test it, there still chances that the library has some issues. (Also, the library lacks in-game tests. All tests are done out of game.)
Can you provide some feedbacks so I can feel safe to mark its version number as release.

1. How is the CPU and memory usage in Wow 8.0? Does it cause any FPS drop?
2. How big is the compressed data? Compared to uncompress data and LibCompress?
3. Anything unclear in the Documentation?
4. Does LibDeflate produce any Lua Error in game?
5. Have you encountered any critical bug that LibDeflate corrupts data? ( Decompress compressed data does not give original data?)
6. If you have time, can you dump some big input data of your addon passed to LibDeflate as Github Gists for me to download? For test cases purpose.

Thanks a lot.

I have found an incorrect usage of LibDeflate in your code:

local decompressedData, status = LibDeflate:DecompressDeflate(compressedData);
	if status == -1 then
		error(RED("[AddOn_TotalRP3.Compression.decompress ERROR]:") .. "\nCould not decompress data \"" .. GREY(tostring(compressedData)) .. "\"");
	end

The 2nd return value is undefined on decompress failure. You should check if the first return value is nil.
Correct Usage:

local decompressedData, status = LibDeflate:DecompressDeflate(compressedData);
	if decompressedData == nil then
		error(RED("[AddOn_TotalRP3.Compression.decompress ERROR]:") .. "\nCould not decompress data \"" .. GREY(tostring(compressedData)) .. "\"");
	end

I will emphasize this when I tag the version of LibDeflate as v1.0
Can you tell me why you were checking if "status" is -1, so I can fix the doc that confuses people?

Hello. Sorry for not replying earlier, as you can guess things are quite busy these days ^^

1. I have not done proper testing of CPU and memory usage. I have not seen any FPS issue, but for now we are only using LibDeflate in some specific workflows that require a user interaction, so we do not compress and decompress data that often in the lifetime of the addon (RP profiles are now non-compressed as they need to be human readable by game masters).
2. I have tested it with a large Total RP 3: Extended campaign created by a user, and the serialized non-compressed version was 162.4KB while the compressed version was 26.01KB, so 8 times smaller. At the rate used for exchanging addon data (which increased a little bit with patch 8.0.1) that campaign went from taking 1 minute and 32 seconds to be sent to another player uncompressed to only 19 seconds! I can no longer compare with LibCompress without doing a lot of changes to my addon, unfortunately.
3. The documentation was quite clear. The function are few but exactly what is needed. Switching from LibCompress to LibDeflate was super easy.
4. I never got a single Lua error from LibDeflate, even when trying weird stuff during development.
5. I never got a single issue with corrupted data. The data has always been perfectly received on the other end :)
6. Here are links for the campaign I used for testing. We are using a simple serialization algorithm for now that basically makes it easy to unserialize on the other end by doing a loadstring() (in an empty environment, of course). This probably means a lot of repetitive characters like " { } , that will benefit from the compression.
   • Uncompressed campaign serialized as a string
   • Compressed campaign

I will fix the incorrect usage, thanks for pointing that out :)

Thanks. LibDeflate v1.0.0 had been released.