You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What do you think about #68?
I've been doing some tests and even though it's difficult to reproduce the behavior of dwarfs blocking so we might not be able to do a proper comparison until it's actually implemented, but I think LZHAM is designed exactly for this kind of use case.
The developer originally intended it for compressing videogames resources if I remember correctly, which obviously need to be loaded as fast as possible. State of the art in commercial alternatives come from Oodle's family of compressors.
Personally, I found the high compression levels of dwarfs to be off-putting. I just can't use them because of the slow reading times. It's like working on an extremely old disk, and the CPU is struggling the whole time too. Now with LZHAM instead, it just might get fast enough to be usable...
It features a zlib-like API for convenience on top of the native low-level API from the codec itself.
Now, I can't decide wether to recommend it as a replacement for lzma or just an addition.
For starters, it seems like the two algorithms are similar enough to be a binary choice. Let's say it's an improved high compression level and call it quits. But on the other hand, some tests might suggest lzham's ratio isn't quite up there on par with lzma's, especially because it's got no exe filters (which we may get from somewhere else, there are several ready to plug in). If that's the case, maybe lzma can stay as an 'ultra' mode. Which would be very confusing from a user's perspective because the highest levels will compress faster than the previous, especially if lzma gets replaced with fast-lzma2.
Still, what do you think?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
What do you think about #68?
I've been doing some tests and even though it's difficult to reproduce the behavior of dwarfs blocking so we might not be able to do a proper comparison until it's actually implemented, but I think LZHAM is designed exactly for this kind of use case.
The developer originally intended it for compressing videogames resources if I remember correctly, which obviously need to be loaded as fast as possible. State of the art in commercial alternatives come from Oodle's family of compressors.
Personally, I found the high compression levels of dwarfs to be off-putting. I just can't use them because of the slow reading times. It's like working on an extremely old disk, and the CPU is struggling the whole time too. Now with LZHAM instead, it just might get fast enough to be usable...
It features a zlib-like API for convenience on top of the native low-level API from the codec itself.
Now, I can't decide wether to recommend it as a replacement for lzma or just an addition.
For starters, it seems like the two algorithms are similar enough to be a binary choice. Let's say it's an improved high compression level and call it quits. But on the other hand, some tests might suggest lzham's ratio isn't quite up there on par with lzma's, especially because it's got no exe filters (which we may get from somewhere else, there are several ready to plug in). If that's the case, maybe lzma can stay as an 'ultra' mode. Which would be very confusing from a user's perspective because the highest levels will compress faster than the previous, especially if lzma gets replaced with fast-lzma2.
Still, what do you think?
Beta Was this translation helpful? Give feedback.
All reactions