|
As far as I know, LOLZ uses RZM filters—evidently enhanced with additional filters and concepts—which are then combined with LZNA compression, incorporating some form of CM (Context Mixing). This is why the codec is slow during compression but fast during decompression.
I haven't really encountered a scenario where it slows down specifically toward the end of the compression process; however, LDMF could be a potential cause—which is to be expected if it has to search for, and subsequently finds, a large number of matches. I have, however, experienced extreme slowdowns during certain phases, likely due to the CM component. The game *SCPT* exhibits this behavior with some of its data files (specifically, a certain section of one of the audio archives).
Regarding multithreading, is it possible to make the processes independent? In other words, if I compress using only 1 or 2–4 threads, could it decompress the data using, say, 16 threads (or vice versa)? Also, is there a way to control memory usage during decompression—similar to how it’s handled in LOLZ—accepting a slight loss in speed in exchange for more stable operation?
|