Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use libdeflate [de]compressor under conditional compilation #13

Open
wqweto opened this issue May 23, 2019 · 3 comments
Open

Use libdeflate [de]compressor under conditional compilation #13

wqweto opened this issue May 23, 2019 · 3 comments

Comments

@wqweto
Copy link
Owner

wqweto commented May 23, 2019

Pros

  • better compression ratio
  • better decompression speed

Cons

@tannerhelland
Copy link
Contributor

A few additional thoughts...

Pros

  • better compression speed (even at minimum comp. levels)
  • faster crc32

Cons

  • libdeflate only implements "one-shot" deflate/inflate API. There is no streaming API. Probably not a deal-breaker for most users, but this would prevent future Zip64 support (via libdeflate, anyway).

Misc

  • as noted in the libdeflate README, compiling via VS is "supported" but the perf hit is large. The recommended MinGW toolchain further complicates custom stdcall building (which is why I just stick with official binaries and DispCallFunc wrappers... it's ugly, but the perf benefits are worth it IMO)
  • if conditional compilation introduces too many complexities, another implementation option could be a public sub like...
Public Sub SetLibDeflatePath(pathToDll As String)
  mhLibDeflate = LoadLibrary(pathToDll)
  If (mhLibDeflate <> 0) Then
    'Cache proc addresses for relevant functions
  End If
End Sub

...with relevant deflate/inflate code gently modified...

If (mhLibDeflate <> 0) Then
   'Use libdeflate
Else
   'Use thunk
End If

Hard to know what is "best" for the average VB6 consumer of the class :/

@wqweto
Copy link
Owner Author

wqweto commented May 24, 2019

10x for input, Tanner.

I think gcc/mingw must support stdcall on x86 targets. Although still have to weight in benefits of using official release dlls against custom built stdcall ones.

@tannerhelland
Copy link
Contributor

Yes, GCC does support stdcall exports, but I am fuzzy on "best practices" for handling things like name-mangling with it...

tbh I have moved more and more toward p/invoke-style DispCallFunc wrapping of official 3rd-party release builds in recent years, mostly because maintaining custom stdcall builds is tedious and I find few repo owners are interested in merging patches to simplify cross-building. But it's also entirely possible that I am just getting lazier... :)

Either way, thank you for investigating this feature! (And sorry for popping into this repo so often; it's one of the few I watch on GitHub as I've deployed it to quite a few client projects - across many production environments, it works excellently.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants