When doing a vcbuild.bat Release, I'll get a lib directory like this:
$ ls -1Ssh Release/lib/
total 303M
263M v8_base.lib
22M openssl.lib
7.2M v8_snapshot.lib
6.2M v8_nosnapshot.lib
4.8M uv.lib
480K zlib.lib
88K http_parser.lib
Debug is much better, but still:
$ ls -1Ssh Debug/lib/
total 102M
83M v8_base.lib
14M openssl.lib
2.1M uv.lib
1.6M v8_snapshot.lib
1.3M v8_nosnapshot.lib
352K zlib.lib
80K http_parser.lib
Two things I don't understand about all this:
I'm on Windows 7 64bit.
Edit I just figured out that the default target_arch is ia32, not x64, regardless what architecture the host machine is. So the numbers above refer to a 32bit build. 64bit numbers are a little bigger (309M / 128M).
Why is v8 THIS big?
Is it perhaps because of its dependencies and features? Like:
$ ls -1Ssh Release/obj/v8_base/|head -15
total 264M
5.1M hydrogen.obj
4.7M objects.obj
4.6M lithium-codegen-ia32.obj
4.4M lithium-ia32.obj
4.3M runtime.obj
4.3M hydrogen-instructions.obj
4.2M lithium-allocator.obj
4.1M lithium-gap-resolver-ia32.obj
3.7M compiler.obj
3.7M isolate.obj
3.5M v8.obj
3.4M lithium.obj
3.3M heap.obj
3.3M api.obj
Still, seems somewhat big...
Why does a Debug build yield much smaller lib files?
Is it perhaps these optimizations for speed I found in common.gypi?
'Release': {
...
'msvs_settings': {
'VCCLCompilerTool': {
'RuntimeLibrary': 0, # static release
'Optimization': 3, # /Ox, full optimization
'FavorSizeOrSpeed': 1, # /Ot, favour speed over size
'InlineFunctionExpansion': 2, # /Ob2, inline anything eligible
Took me a while to figure out why the V8 engine was building such large builds on Windows.
There's an option -D"component=shared" that you can use when building V8 to create a smaller lib v8.lib (~250kb) and the dlls needed V8.dll (~12mb), icui18n.dll (~2.5mb), icuuc.dll (~1.5mb).
From the V8 Directory:
third_party\python_26\python.exe build\gyp_v8 -G msvs_version=2010 -Dtarget_arch=x64 -D"component=shared" -G
The real answer is that you didn't choose the "release" build option. Release mode cuts down the size significantly.