From: bertrand g. <ber...@gm...> - 2006-12-02 16:11:34
|
Hi all, I need to reduce the size of my packages to increase the speed access for the web user. I have already use some good techniques to reduce the size of my web packages... 1=B0) Now I will use dynamic stlport5.0.2 for the stdlib to gain 300Ko/dll (average) instead of the default static linking. 2=B0) I make a strip -s *.dll on my dlls to suppress symbols traces and deb= ug info 3=B0) I make a zip of my dlls But now, if possible, I would like gain size yet to obtain the same size or more little than a VC6-7 release dll, Why the "bad" VC dll is yet more little than a "good" mingw dll ? How they do this ?! What I have to do now ? ( I am open to unoffical and violent techniques ) Somebody can help me ? PS : I use 3.4.4 mingw compilator (-O2 optimisation) and by example for the osg lib (libosg.dll) I obtain a size of 2.6Mo against the 1,17Mo the official VC7 equivalent --=20 Bertrand Greslier http://www.cooki3d.org |
From: Brian D. <br...@de...> - 2006-12-02 16:42:36
|
bertrand greslier wrote: > Why the "bad" VC dll is yet more little than a "good" mingw dll ? How > they do this ?! > What I have to do now ? ( I am open to unoffical and violent > techniques ) > Somebody can help me ? Without any details it's hard to say. The MinGW gcc uses the stabs debug format by default, which is a somewhat outdated and inefficient format, and creates huge amounts of debug info, especially in the face of C++. Compile without -g or use -gdwarf-2 to avoid this. But stripping the DLL would remove all debug info anyway. Also, MinGW gcc does not include a dynamic libstdc++ which also tends to create huge binaries when there's lots of C++ involved. I think if you search the archives you will find a recipe for creating a shared libstdc++ which should cut down the size considerably. But you also said you were using stlport so maybe this doesn't affect you. If you are comparing a statically linked g++ binary to a MSVC++ binary, it's a somewhat unfair comparison because the C++ runtime for Microsoft's C++ STL gets installed in the system32 directory as MSVCP*.DLL and is shared by all users of the system. If you really want to compare apples to apples you would need to compare shared to shared and static to static. If your code makes heavy use of exceptions there is also the fact that gcc currently uses SJLJ exception handling whereas MSVC++ uses the native SEH. I don't know how much of a size difference this makes, but you could try building your app using the DW2 EH enabled gcc binaries that are available at the file release area of sourceforge. It would be very nice if eventually gcc supported SEH, but that doesn't seem to be in the cards right now. There are some other gcc options you might want to investigate, such as -Os and "-ffunction-sections -fdata-sections -Wl,-gc-sections". I don't know how much of an effect these would have, if any. And there's always the option of PE-packers like UPX. Brian |
From: bertrand g. <ber...@gm...> - 2006-12-02 17:14:04
|
> .... But > stripping the DLL would remove all debug info anyway. Yes I have strip my dlls. ... But you also > said you were using stlport so maybe this doesn't affect you. Yes I use a shared libstlport.5.0.dll . If you are comparing a statically linked g++ binary to a MSVC++ binary, > it's a somewhat unfair comparison because the C++ runtime for > Microsoft's C++ STL gets installed in the system32 directory as > MSVCP*.DLL and is shared by all users of the system. If you really want > to compare apples to apples you would need to compare shared to shared > and static to static. all my libs are shared, stlport is also shared, never static. Perhaps only C function link _free, _printf are not in my libs, I don't know exactly why, it is static linked ? I believe I compare shared with shared. I have give the worst example because this is the most insterressant to study. libosg.dll not stripped => ~40Mo libosg.dll stripped => ~2,9Mo libosg.dll + use eternal libstlport.5.0.dll linking with dynamically + stripped => ~2,6Mo VC osg.dll in the official OpenSceneGraph win32 package => 1,17Mo It is really my results, I try to compare apples to apples. In most case and for most people the size is not important. For my web solution it is important. If your code makes heavy use of exceptions there is also the fact that > gcc currently uses SJLJ exception handling whereas MSVC++ uses the > native SEH. I don't know how much of a size difference this makes, but > you could try building your app using the DW2 EH enabled gcc binaries > that are available at the file release area of sourceforge. It would be > very nice if eventually gcc supported SEH, but that doesn't seem to be > in the cards right now. Yes, I will try to study this with -noexception to compare the size. There are some other gcc options you might want to investigate, such as > -Os and "-ffunction-sections -fdata-sections -Wl,-gc-sections". I don't > know how much of an effect these would have, if any. > > And there's always the option of PE-packers like UPX thanks you, I will try this also and study more the man pages. Regards, -- Bertrand Greslier http://www.cooki3d.org |
From: bertrand g. <ber...@gm...> - 2006-12-03 13:35:53
|
YEAH !! thanks you Brian ! with the -fno-exceptions option and with all other technics already says I have a libosg.dll size of 1.6Mo, it is a very great result ! I have read in man page of gcc than exceptions are enable by default on C++ code, it takes 1Mo on this library ! Regards, Bertrand. On 12/2/06, bertrand greslier <ber...@gm...> wrote: > > > .... But > > stripping the DLL would remove all debug info anyway. > > > Yes I have strip my dlls. > > ... But you also > > said you were using stlport so maybe this doesn't affect you. > > > Yes I use a shared libstlport.5.0.dll . > > If you are comparing a statically linked g++ binary to a MSVC++ binary, > > it's a somewhat unfair comparison because the C++ runtime for > > Microsoft's C++ STL gets installed in the system32 directory as > > MSVCP*.DLL and is shared by all users of the system. If you really want > > to compare apples to apples you would need to compare shared to shared > > and static to static. > > > all my libs are shared, stlport is also shared, never static. Perhaps only > C function link _free, _printf are not in my libs, I don't know exactly why, > it is static linked ? > > I believe I compare shared with shared. I have give the worst example > because this is the most insterressant to study. > libosg.dll not stripped => ~40Mo > libosg.dll stripped => ~2,9Mo > libosg.dll + use eternal libstlport.5.0.dll linking with dynamically + > stripped => ~2,6Mo > VC osg.dll in the official OpenSceneGraph win32 package => 1,17Mo > It is really my results, I try to compare apples to apples. > In most case and for most people the size is not important. > For my web solution it is important. > > If your code makes heavy use of exceptions there is also the fact that > > gcc currently uses SJLJ exception handling whereas MSVC++ uses the > > native SEH. I don't know how much of a size difference this makes, but > > you could try building your app using the DW2 EH enabled gcc binaries > > that are available at the file release area of sourceforge. It would be > > very nice if eventually gcc supported SEH, but that doesn't seem to be > > in the cards right now. > > > Yes, I will try to study this with -noexception to compare the size. > > There are some other gcc options you might want to investigate, such as > > -Os and "-ffunction-sections -fdata-sections -Wl,-gc-sections". I don't > > > > know how much of an effect these would have, if any. > > > > And there's always the option of PE-packers like UPX > > > thanks you, I will try this also and study more the man pages. > > Regards, > -- > Bertrand Greslier > http://www.cooki3d.org > -- Bertrand Greslier http://www.cooki3d.org |
From: bertrand g. <ber...@gm...> - 2006-12-03 15:21:17
|
The rest of my investigations -Os gain 300Ko "-ffunction-sections -fdata-sections -Wl,-gc-sections" seem has no effects this final result is 1.3Mo for libosg.dll example. Now it is ok for me ;-) On 12/3/06, bertrand greslier <ber...@gm...> wrote: > > > YEAH !! > thanks you Brian ! > with the -fno-exceptions option and with all other technics already says I > have a libosg.dll size of 1.6Mo, it is a very great result ! > I have read in man page of gcc than exceptions are enable by default on > C++ code, it takes 1Mo on this library ! > > Regards, > Bertrand. > > On 12/2/06, bertrand greslier <ber...@gm...> wrote: > > > > > > .... But > > > stripping the DLL would remove all debug info anyway. > > > > > > Yes I have strip my dlls. > > > > ... But you also > > > said you were using stlport so maybe this doesn't affect you. > > > > > > Yes I use a shared libstlport.5.0.dll . > > > > If you are comparing a statically linked g++ binary to a MSVC++ binary, > > > it's a somewhat unfair comparison because the C++ runtime for > > > Microsoft's C++ STL gets installed in the system32 directory as > > > MSVCP*.DLL and is shared by all users of the system. If you really > > > want > > > to compare apples to apples you would need to compare shared to shared > > > > > > and static to static. > > > > > > all my libs are shared, stlport is also shared, never static. Perhaps > > only C function link _free, _printf are not in my libs, I don't know exactly > > why, it is static linked ? > > > > I believe I compare shared with shared. I have give the worst example > > because this is the most insterressant to study. > > libosg.dll not stripped => ~40Mo > > libosg.dll stripped => ~2,9Mo > > libosg.dll + use eternal libstlport.5.0.dll linking with dynamically + > > stripped => ~2,6Mo > > VC osg.dll in the official OpenSceneGraph win32 package => 1,17Mo > > It is really my results, I try to compare apples to apples. > > In most case and for most people the size is not important. > > For my web solution it is important. > > > > If your code makes heavy use of exceptions there is also the fact that > > > gcc currently uses SJLJ exception handling whereas MSVC++ uses the > > > native SEH. I don't know how much of a size difference this makes, > > > but > > > you could try building your app using the DW2 EH enabled gcc binaries > > > that are available at the file release area of sourceforge. It would > > > be > > > very nice if eventually gcc supported SEH, but that doesn't seem to be > > > in the cards right now. > > > > > > Yes, I will try to study this with -noexception to compare the size. > > > > There are some other gcc options you might want to investigate, such as > > > -Os and "-ffunction-sections -fdata-sections -Wl,-gc-sections". I > > > don't > > > know how much of an effect these would have, if any. > > > > > > And there's always the option of PE-packers like UPX > > > > > > thanks you, I will try this also and study more the man pages. > > > > Regards, > > -- > > Bertrand Greslier > > http://www.cooki3d.org > > > > > > -- > Bertrand Greslier > http://www.cooki3d.org > -- Bertrand Greslier http://www.cooki3d.org |