VC7 static libs, why so big?
Chris Losinger
We sell a graphics toolkit that combines functionality found in
serveral public domain toolkits (JpegLib, LibTiff, etc) along with our
own libraries. The toolkit is delivered as a single static .LIB.
We accomplish this in VC6 by creating a high-level .LIB that is
dependent on all of the other .LIBs. The library-maker (whatever it's
called) pulls all of the supplementary .LIBs into one master .LIB. The
size of a release build of this, in VC6, is around 3MB.
Sadly, in VC7, the master .LIB is well over 10MB. Yet, none of the sub
libs are over 300K (in either VC6 or VC7).
This is a release build, no debug info, no MFC, the same project
settings that the VC6 uses (if the conversion is OK).
What is VC7 doing that it would triple the size of the resulting .LIB?
-c
Will Dean
>
> Last I got a response from Microsoft regarding huge increases in size
> (in general, not just lib's) was "RAM and disk is cheap". I think that
> answer says it all...
I think they were really trying to say 'support desk jockeys are cheap'.
Will
Mike
>We sell a graphics toolkit that combines functionality found in
>serveral public domain toolkits (JpegLib, LibTiff, etc) along with our
>own libraries. The toolkit is delivered as a single static .LIB.
<snip>
>The size of a release build of this, in VC6, is around 3MB.
>
>Sadly, in VC7, the master .LIB is well over 10MB. Yet, none of the sub
>libs are over 300K (in either VC6 or VC7).
Last I got a response from Microsoft regarding huge increases in size
(in general, not just lib's) was "RAM and disk is cheap". I think that
answer says it all...
--
Mike
Chris Losinger
>Last I got a response from Microsoft regarding huge increases in size
>(in general, not just lib's) was "RAM and disk is cheap". I think that
>answer says it all...
i wish bandwidth and server space was cheap, too. that's what makes
this tough for my company - libs this size are far too large to
distribute and host.
MS really screwed up, if this was intentional. IMHO.
-c
Mike
>Mike <a...@b.c.de> wrote:
>
>>Last I got a response from Microsoft regarding huge increases in size
>>(in general, not just lib's) was "RAM and disk is cheap". I think that
>>answer says it all...
>
>i wish bandwidth and server space was cheap, too.
That's what I tried to tell that MS person. Unfortunately the only
answer I got was silence... :-(
> that's what makes
>this tough for my company - libs this size are far too large to
>distribute and host.
Then, don't distribute VC7 libs. Really. VC7 can still read VC6 libs I
hope? If you start to (only) distribute VC7 libs you effectively kill
off all (still in majority AFAIK) VC6 users.
On the other hand, maybe the VC7 libs just contain a lot of "air"? How
well do these VC7 libs compress compared to the VC6 versions?
>MS really screwed up, if this was intentional. IMHO.
I don't think it's intentional. It's just that it seems they have
stopped giving a damned (easy once you're a monopoly) about quality
(here I use size as a quality-meter - lack of size displays you care
about quality, and then the chances are good you care about quality at
all levels).
--
Mike
Chris Losinger
>Then, don't distribute VC7 libs. Really. VC7 can still read VC6 libs I
>hope? If you start to (only) distribute VC7 libs you effectively kill
>off all (still in majority AFAIK) VC6 users.
unfortunately, the libs use the STL. and MS has changed the STL enough
that the two versions won't work together. (unfortunately, STL isn't a
header-only thing like it's assumed). various methods have changed
their signatures, classes missing, etc..
i've also found that by reducing the number of .CPPs in my project (by
combining them), i can get the .LIB size to start to fall. but, that's
not a good solution.
>
>On the other hand, maybe the VC7 libs just contain a lot of "air"? How
>well do these VC7 libs compress compared to the VC6 versions?
some of them do compress well, some don't. i guess i'll have to bite
the bullet and pay for more bandwidth. *sigh*
-c
Mike
>Mike <a...@b.c.de> wrote:
>
>>Then, don't distribute VC7 libs. Really. VC7 can still read VC6 libs I
>>hope? If you start to (only) distribute VC7 libs you effectively kill
>>off all (still in majority AFAIK) VC6 users.
>
>unfortunately, the libs use the STL. and MS has changed the STL enough
>that the two versions won't work together.
The imperfection is yours.
Don't ever, EVER, mention "STL" types in an interface between what's
to be "modules" unless you're prepared to get a monolith. Actually, so
long as we don't have a C++ ABI don't ever mention a C++-only type in
an interface. That just won't work (if you're to be compatible with
anything but the compiler and _exact_ library you used - this can
break by a such simple thing as fixing a header-file bug, e.g. from
the Dinkumware site).
>i've also found that by reducing the number of .CPPs in my project (by
>combining them), i can get the .LIB size to start to fall. but, that's
>not a good solution.
That seems reasonable. As I believe you know a .lib file is a
collection of object files and their symbols. Could it be that MS
messed up so badly that they added n*y bytes in the "new" VC7 library
format instead of n+y bytes/object file? As I don't touch VC7 myself I
can't really tell.
>>On the other hand, maybe the VC7 libs just contain a lot of "air"? How
>>well do these VC7 libs compress compared to the VC6 versions?
>
>some of them do compress well, some don't. i guess i'll have to bite
>the bullet and pay for more bandwidth. *sigh*
Either that, or you create C-like interfaces (which _is_ the only type
that is portable/has a de-facto ABI) and just ship the same old VC6
libraries.
There are other ways, but that would require you to ship the C++ -> C
wrapper code in source-form, something I'm not sure you're even
allowed to do with VC7 (read the EULA, it might prove enlightening).
--
Mike
Jonathan Caves [MSFT]
While it is true that for Visual C++ 7.0 we did ship a much more conformant
version of STL which did increase the size of the static lib -- mostly due
to the need to correctly handle locales -- it should not result in the
increase you are seeing. So I have some questions:
What compiler options are you using?
Do you use the static version or dynamic version of STL?
Do you use the static version or dynamic version of CRT?
Are you linking against a debug or retail version of the CRT?
--
Jonathan Caves
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Chris Losinger" <delet...@spam.smalleranimals.com> wrote in message
news:k32amuob9li9k6kmd...@4ax.com...
Chris Losinger
>Chris: I would really like to dig into why your libs have grown so much.
>While it is true that for Visual C++ 7.0 we did ship a much more conformant
>version of STL which did increase the size of the static lib -- mostly due
>to the need to correctly handle locales -- it should not result in the
>increase you are seeing. So I have some questions:
>
Thanks for the response.
>What compiler options are you using?
This is the C/C++ "Command Line" stuff for the "Release DLL" version
(see below):
/O1 /Ob1 /I "crypto31" /I "palib" /I "jpeglib" /I "libpng" /I
"libtiff" /I "zlib" /I "tlalib" /D "NDEBUG" /D "WIN32" /D "_WINDOWS"
/GF /FD /EHsc /MD /Gy /YX"stdafx.h" /Fp".\ReleaseDLL/ISLib.pch"
/Fo".\ReleaseDLL/" /Fd".\ReleaseDLL/" /W3 /nologo /c
This is the "Librarian" command line stuff:
/OUT:"ReleaseDLL\ISLibMD22.lib" /NOLOGO
>Do you use the static version or dynamic version of STL?
I'm not sure. I don't think we explicitly specify anywhere.
>Do you use the static version or dynamic version of CRT?
Both (but not in the same .LIB). We ship four versions of our libs:
Debug-multithreaded (for use with to the debug-multithreaded CRT but
with no debug info in the LIB), Debug-multithreaded-DLL (for the
debug-multithreaded-DLL CRT but with no debug info in the LIB) also
release-multi and release-multi-DLL version.
Again, there's no MFC here.
The sizes of these are:
10,252K (release multi DLL)
10,208K (debug multi DLL)
11,085K (release multi)
10,982K (debug multi)
For reference, the VC6 libs are 3613K, 3581K, 3937K and 3960K,
repsectively.
Also, for reference, a full debug build with VC7 is over 50MB (19MB
for VC6)
>Are you linking against a debug or retail version of the CRT?
We're not linking at all right now, this is strictly static lib
creation. Static libs are the final product in this situation.
-c
Chris Losinger
>that is portable/has a de-facto ABI) and just ship the same old VC6
>libraries.
>
all of the external interfaces are C (no C++ at all, externally).
-c
Jonathan Caves [MSFT]
library using Visual C++ 6.0, Visual C++ 7.0 and Visual C++ 7.*
#include <iostream>
void f()
{
std::cout << "Hello" << std::endl;
}
void g()
{
std::cout << "Goodbye" << std::endl;
}
I used /O1 /Ob1 /MD /EHsc
Here are the sizes of the libs that resulted
Visual C++ 6.0 - 3952 bytes
Visual C++ 7.0 - 10528 bytes - 2.66 times larger than 6.0
Visual C++ 7.* - 11690 bytes - 2.95 times larger than 6.0
So I dumped the symbols from each lib:
The 6.0 lib has 24 symbols
The 7.0 lib has 47 symbols
The 7.1 lib has 51 symbols
Almost all the extra symbols are STL related -- especially locale related.
It does look like we are paying quite a hefty price for a fully conformant
version of the Standard C++ Library.
I've gotten in touch with the libraries team here to see if they have any
comments about these numbers.
--
Jonathan Caves
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
"Chris Losinger" <delet...@spam.smalleranimals.com> wrote in message
news:d1jamu0q4o989nqk5...@4ax.com...
Nish
L's main problem is the extra download size of the files and thus the extra
resultant bandwidth, the zip sizes would be quite meaningful here. Perhaps
the 2.66 ratio might decrease to a more decent ratio when zipped.
Regards,
Nish
"Jonathan Caves [MSFT]" <no_spam_...@microsoft.com>
Chris Losinger
>It would be intersting to see the zipped sizes of each of those? Since Chris
>L's main problem is the extra download size of the files and thus the extra
>resultant bandwidth, the zip sizes would be quite meaningful here. Perhaps
>the 2.66 ratio might decrease to a more decent ratio when zipped.
the zipped ratios are about the same. meaning i get a 6MB ZIP file for
the VC7 libs, vs. a 3MB ZIP for the VC6.
-c