wip: spanification and major rewrite draft

[PaulusParssinen]

wip mess. way too big PR but seems to be the only way when you're touching every single line of the project, sad.

[PaulusParssinen]

Most of the work done. Now need rework the most used surface of the library: the initial parsing with ShockwaveFile.Read(..). Not happy with it current state.

[thenameless314159]

Hello, I wasted few hours of my time to make my own "spanification" (read-only, only tags and abc file) with a benchmark for the three available implementations (yours, mine and the default stream-based one) and figured out that unless we find a workaround the needed re-allocation to decompress ZLib data we won't beat the original implementation in term of allocations. Which is a shame ngl, and it seems that it won't be worked on cf. dotnet/runtime#16923

I won't be working further on the project since the original is okay but you can find the results and repo here : thenameless314159/DotNetFlashDecompiler#1

[PaulusParssinen]

Hey, your version is awesome! I was also considering to use SequenceReader for my "spanification" but chose not to - can't remember exactly why, it's been long time..

The compression being inside the file format is very annoying and painful. I removed LZMA compression support from the library prematurely when I saw .NET team prioritizing a inbox solution for it in .NET 7 IIRC but that got dropped AFAIK and pushed into the "Future" limbo. I have pretty much given up on all System.IO issue priotization and just hope that we get progress on following issues in next few years dotnet/runtime#39327 dotnet/runtime#62113. ZLibEncoder/Decoder would probably help us.

The original wrapped ZLibStream solution is the most memory efficient for now. Wrapping one inside S.IO.Pipelines would be way too heavy/expensive with all of its async machinery for this, I fear.

[thenameless314159]

The original wrapped ZLibStream solution is the most memory efficient for now. Wrapping one inside S.IO.Pipelines would be way too heavy/expensive with all of its async machinery for this, I fear.

Unfortunately I had written most of the ABC file parsing logic already before making the bench, i would have saved a lot of time if I had made it earlier :/

Indeed but it was written a while ago, most ABC file properties could be abstracted with auto-implemented interfaces nowadays but it wasn't a thing at the time, and the lack of nullable support makes it kind of hard to deal with also. I was about to do it but this memory issue set me back, again it's really a shame that we cannot use span-based APIs for decompression from the BCL.

Altough it seems that it have been implemented by a few people according to the issues you've mentionned, i'll check it when i'll have the time and maybe try to implement it

[ArachisH]

Going to be pushing the current dev branch to nuget as 0.1.0 soon, so when these changes are introduced we can bump the major and release as 1.0.0.

[PaulusParssinen]

Gonna re-do this spanification is "smaller" pull requests.