dynarithmic / twain_library

Dynarithmic TWAIN Library, Version 5.x
Apache License 2.0
60 stars 25 forks source link

Big size of dll's #48

Closed gerardcarbo closed 1 year ago

gerardcarbo commented 1 year ago

I've seen that the size of the binary dtwain dll's are around 10-15MB in release. I think it is a quite big size for a twain wrapper. Is it normal?

dynarithmic commented 1 year ago

The DLL includes image file libraries such as libtiff, libpng, etc., compression libraries such as zlib, cryptography libraries for creating encrypted PDF files, etc. These are included in one DLL instead of spread out over many DLL's.

So by the time you add up the size of the potential individual DLL's there, should be little difference between that and just one DLL with all the components.

dynarithmic commented 1 year ago

I experimented a bit, and was able to reduce the 32-bit Unicode DLL to a little over 9 MB (I didn't try the 64-bit DLL). However, the following changes had to be made:

1) The compiler and runtime used is based on Visual Studio 2019 (not 2015 as it is now).
2) The exception handling code is removed.
3) The code to record the function call stack was removed (this is for DTWAIN_SetTwainLog). 4) Final optimization chosen was for size, and not speed (currently it is chosen for speed).

Whether this is worth 1.5 MB savings, not sure (especially where the exception handling is turned off). But it is something to consider in the future.

gerardcarbo commented 1 year ago

Ok, thanks for the response. I think the savings are not worth. On the other side I've made some fast calculations and for image+zip libraries it should take no more than 2MB. Maybe it's the crypto/pdf creation stuff, but I would say that ~8MB it's quite a lot for this.

dynarithmic commented 1 year ago

There are about 1000 exported functions (many are wrappers for TWAIN setting and getting certain TWAIN capabilities). For example, the DTWAIN_EnumBrightnessValues function is exported, which is a wrapper to DTWAIN_GetCapValues using ICAP_BRIGHTNESS as the capability value.

You also have a couple of boost static libraries, plus the C++ runtime to add to the mix.

The imaging part of the entire library has been under serious consideration of being changed, since FreeImage (the wrapper that uses the third-party imaging libraries) is no longer supported. ImageMagick and a couple of others have been considered, but no changes have been started (yet).

gerardcarbo commented 1 year ago

Ok, great! thanks.

dynarithmic commented 1 year ago

I was able to shave off about 4MB from the size of the DLL's by removing unused imaging code from the FreeImage library, plus specifying that the DLL's be optimized for minimum size.

I haven't fully tested them, but shortly I will put them in the development branch. I will let you know of any further progress.

gerardcarbo commented 1 year ago

About 1/3 of savings! Nice. Still a little heavy for my taste, but good work!!

dynarithmic commented 1 year ago

New DLLs are available here.

You can try them out to see if there are any issues.

dynarithmic commented 1 year ago

Version 5.3.0.3 addresses the issue somewhat of the DLL size. I will be closing the ticket, but will be wary of any size increases from this point further.