[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Iain Buclaw changed: What|Removed |Added CC|ibuc...@gdcproject.org | --

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 CC|

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Iain Buclaw changed: What|Removed |Added Priority|P4 |P1 Severity|enhancement

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Iain Buclaw changed: What|Removed |Added Priority|P1 |P4 --

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Shriramana Sharma changed: What|Removed |Added CC||samj...@gmail.com --

Re: Why do static arrays affect executable size?

Thanks for the clarifications.

Re: Why do static arrays affect executable size?

On Saturday, 11 February 2017 at 00:16:04 UTC, sarn wrote: If you explicitly initialise the array to all 0.0, you should see it disappear from the binary. I was actually wondering whether initialisation would make a difference, so thank you for this. Bastiaan.

Re: Why do static arrays affect executable size?

On Friday, 10 February 2017 at 15:12:28 UTC, Jonathan M Davis wrote: Module-level and static variables all get put in the executable. So, declaring a static array like that is going to take up space. A dynamic array would do the same thing if you gave it a value of that size. The same thing

Re: Why do static arrays affect executable size?

On Friday, February 10, 2017 11:21:48 Bastiaan Veelo via Digitalmars-d-learn wrote: > // enum int maxarray = 0; > enum int maxarray = 2_000_000; > > double[maxarray] a, b, c, d; > > void main() {} > > > Compiled using "dub build --arch=x86_64 --build=release" on > Windows (DMD32 D Compiler

Re: Why do static arrays affect executable size?

On Friday, 10 February 2017 at 11:21:48 UTC, Bastiaan Veelo wrote: // enum int maxarray = 0; enum int maxarray = 2_000_000; double[maxarray] a, b, c, d; void main() {} Compiled using "dub build --arch=x86_64 --build=release" on Windows (DMD32 D Compiler v2.073.0), the exe size is 302_592

Why do static arrays affect executable size?

// enum int maxarray = 0; enum int maxarray = 2_000_000; double[maxarray] a, b, c, d; void main() {} Compiled using "dub build --arch=x86_64 --build=release" on Windows (DMD32 D Compiler v2.073.0), the exe size is 302_592 bytes v.s. 64_302_592 bytes, depending on the array length. Is that

Re: hello world executable size

On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote: On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote: I was curious if binary sizes had decreased because of the changes Ilya had been making to try and scope imports

Re: hello world executable size

On Sunday, 28 June 2015 at 09:27:56 UTC, Joakim wrote: Another check that would be more worthwhile but harder to measure would be speed of compilation of druntime/phobos, especially since speed of compilation is considered a key selling point of D. Harder to measure because it depends on

Re: hello world executable size

/pull/3443 Woah. Why would removing an import increase the filesize? I didn't get that either, maybe he meant the PR that yours fixed is the one that doubled it? it's the PR that's linked when I zoomed in on executable size in 'Hello World'. It's not visible at first(I guess because the PR

Re: hello world executable size

On Sunday, 28 June 2015 at 10:11:08 UTC, Vladimir Panteleev wrote: No, he's right. Removing the import doubled the filesize of a helloworld binary. Ah, I didn't want to download the full 90 MBs graph data again to see it. Yes, I see it now. On Sunday, 28 June 2015 at 09:58:35 UTC, Vladimir

Re: hello world executable size

On Sunday, 28 June 2015 at 10:37:15 UTC, Joakim wrote: On Sunday, 28 June 2015 at 10:11:08 UTC, Vladimir Panteleev wrote: No, he's right. Removing the import doubled the filesize of a helloworld binary. Ah, I didn't want to download the full 90 MBs graph data again to see it. Yes, I see it

Re: hello world executable size

On Thursday, 25 June 2015 at 12:15:26 UTC, Joakim wrote: On Thursday, 25 June 2015 at 12:04:26 UTC, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 11:59:24 UTC, Joakim wrote: Took 90 MiB of JSON to see it, but finally got it, funny how executable size swings wildly up to five times

Re: hello world executable size

On Sunday, 28 June 2015 at 09:55:53 UTC, Vladimir Panteleev wrote: On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote: looks like this commit more than doubled the size of hello world https://github.com/D-Programming-Language/phobos/pull/3443 Woah. Why would removing an import increase

Re: hello world executable size

On Thursday, 25 June 2015 at 11:07:11 UTC, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote: I was curious if binary sizes had decreased because of the changes Ilya had been making to try and scope imports better and make them more selective:

Re: hello world executable size

On Sunday, 28 June 2015 at 10:06:20 UTC, Joakim wrote: On Sunday, 28 June 2015 at 09:55:53 UTC, Vladimir Panteleev wrote: On Sunday, 28 June 2015 at 09:46:45 UTC, rsw0x wrote: looks like this commit more than doubled the size of hello world

Re: hello world executable size

://digger.k3.1azy.net/trend/ Took 90 MiB of JSON to see it, but finally got it, funny how executable size swings wildly up to five times larger over the years. :) Anyway, I saw that viewer when you announced it before: any plans to add it to the github PR checks, along with your recent check

Re: hello world executable size

On Thursday, 25 June 2015 at 11:05:00 UTC, Joakim wrote: I was curious if binary sizes had decreased because of the changes Ilya had been making to try and scope imports better and make them more selective: http://digger.k3.1azy.net/trend/ I used nm to try and find some of the symbols using

hello world executable size

selective imports from std.uni, including one at module scope. I tried commenting out that single selective import of std.string.format in std.utf and the same binary compiled and ran fine without any imports of std.string or std.uni, plus it was now 36 KB smaller. :) I realize executable

Re: hello world executable size

imports better and make them more selective: http://digger.k3.1azy.net/trend/ Took 90 MiB of JSON to see it, but finally got it, funny how executable size swings wildly up to five times larger over the years. :) Anyway, I saw that viewer when you announced it before: any plans to add

Re: hello world executable size

On Thursday, 25 June 2015 at 12:04:26 UTC, Vladimir Panteleev wrote: On Thursday, 25 June 2015 at 11:59:24 UTC, Joakim wrote: Took 90 MiB of JSON to see it, but finally got it, funny how executable size swings wildly up to five times larger over the years. :) Anyway, I saw that viewer when you

[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size

https://issues.dlang.org/show_bug.cgi?id=9660 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Component|Optlink |tools --

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Issue 14599 depends on issue 14539, which changed state. Issue 14539 Summary: +508KB (684KB - 1191KB) filesize increase Hello, world binary https://issues.dlang.org/show_bug.cgi?id=14539 What|Removed |Added

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC|

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Assignee|nob...@puremagic.com

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 --- Comment #1 from Jonathan M Davis issues.dl...@jmdavisprog.com --- Lovely. This sort of thing makes it very annoying to add any functionality that's even vaguely related to writeln, and we never organized the modules in Phobos with the idea of

[Issue 14599] Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Depends on||14539 --

[Issue 14599] New: Re-add scratchFile after executable size regression has been fixed

https://issues.dlang.org/show_bug.cgi?id=14599 Issue ID: 14599 Summary: Re-add scratchFile after executable size regression has been fixed Product: D Version: D2 Hardware: x86 OS: Mac OS X Status

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #13 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/239394c6ea98a281c51f95977612cc41866f0b4f Merge pull request #3778

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

- Executable size of hello world explodes from 472K to 2.7M - This problem seems to stem from mixed writeable flags for the .deh/.minfo sections in PIC/non-PIC code. The ld.bfd linker would still try to bracket the sections, even though it previously mapped them to different segments, thereby creating

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #11 from Martin Nowak c...@dawg.eu --- The resolution of this bug implies that the libphobos2.a we're shipping is build with -fPIC. See issue 13149. --

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

from MartinNowak/fix13117 fix Issue 13117 - Executable size of hello world explodes from 472K to 2.7M --

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #7 from Martin Nowak c...@dawg.eu --- Doesn't happen with PIC code either. dmd -fPIC main --

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 Martin Nowak c...@dawg.eu changed: What|Removed |Added Keywords||pull --- Comment #8 from Martin

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #9 from Martin Nowak c...@dawg.eu --- Bug was introduced with https://github.com/D-Programming-Language/dmd/pull/3187 which fixed Issue 11171 - Text relocations in Phobos shared library. --

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #6 from

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #4 from dbr dbugrepor...@gmail.com --- Ok here's more info then: % uname -a Linux laptop 3.11.0-20-generic #35-Ubuntu SMP Fri May 2 21:32:49 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux % file hello hello: ELF 64-bit LSB executable, x86-64,

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #5 from dbr dbugrepor...@gmail.com --- Looked with xxd, there's nothing but a bunch of zeros between those sections. --

[Issue 13117] New: Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 Issue ID: 13117 Summary: Executable size of hello world explodes from 472K to 2.7M Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- Issue does not occur in Windows platform. -m32 With git head: 145,436 bytes With 2.065:138,268 bytes -m64 With git head: 259,584 bytes With 2.065:257,536 bytes --

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC|

[Issue 13117] Executable size of hello world explodes from 472K to 2.7M

https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #3 from Walter Bright bugzi...@digitalmars.com --- I just tried this, and am seeing 394,000 size executables. I cannot reproduce your results. --

[Issue 9660] New: [meta] Not able to debug on Windows starting from ~10 MiB executable size

http://d.puremagic.com/issues/show_bug.cgi?id=9660 Summary: [meta] Not able to debug on Windows starting from ~10 MiB executable size Product: D Version: D2 Platform: All OS/Version: Windows Status: NEW

[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size

http://d.puremagic.com/issues/show_bug.cgi?id=9660 --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-07 15:10:12 MSK --- Some magic like separating a part of the project into a library may or may not help. Eliminating use of templates often helps. E.g. one should

[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size

http://d.puremagic.com/issues/show_bug.cgi?id=9660 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 9660] [meta] Not able to debug on Windows starting from ~10 MiB executable size

http://d.puremagic.com/issues/show_bug.cgi?id=9660 --- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com 2013-03-08 08:49:14 MSK --- (In reply to comment #2) Why did you open this if it's about Issue 6144? Keep issues about actual bugs and not discussions about other issues.

Re: Executable size when compiling with GDC

You can try upx too :) Il giorno mar, 21/02/2012 alle 16.43 +0100, Mars ha scritto: On Tuesday, 21 February 2012 at 13:19:11 UTC, Andrea Fontana wrote: Have you tried to strip executable using --strip or --strip-all? Down to 1 MB, a good start, thanks. I guess that's more bearable.

Re: Executable size when compiling with GDC

On 21.02.2012 16:51, Mars wrote: Hello everybody. Today I've tested GDC (on Windows), and a simple Hello World program results in a 5 MB exe file, while it's only about 200 KB with DMD. Is this normal? What does GDC (GCC?) put in there, to make it so big, and why? Mars I recall debug builds

Executable size when compiling with GDC

Hello everybody. Today I've tested GDC (on Windows), and a simple Hello World program results in a 5 MB exe file, while it's only about 200 KB with DMD. Is this normal? What does GDC (GCC?) put in there, to make it so big, and why? Mars

Re: Executable size when compiling with GDC

Have you tried to strip executable using --strip or --strip-all? Il giorno mar, 21/02/2012 alle 13.51 +0100, Mars ha scritto: Hello everybody. Today I've tested GDC (on Windows), and a simple Hello World program results in a 5 MB exe file, while it's only about 200 KB with DMD. Is this

Re: Executable size when compiling with GDC

On Tuesday, 21 February 2012 at 13:19:11 UTC, Andrea Fontana wrote: Have you tried to strip executable using --strip or --strip-all? Down to 1 MB, a good start, thanks. I guess that's more bearable.

Re: Executable size when compiling with GDC

Lots of symbols and stuff. You can get it down with -ffunction-sections -fdata-sections -Wl,-s,--gc-sections Phobos should also be compiled with -ffunction-sections -fdata-sections to get the whole effect though.

Re: What can be done to reduce executable size?

On 12/16/11 1:12 AM, Jonathan M Davis wrote: Simply making it so that std.file is only imported in std.stdio with version(unittest) cut off _that_ much? Yah, but the matter is more complex. The issue is that std.file pulls std.datetime, which (a) has static this() code, and (b) pulls

Re: What can be done to reduce executable size?

Andrei Alexandrescu: Right now an executable starts at around 218KB, which includes druntime (gc, type info, the works). Importing std.stdio and using writeln() only adds a couple of KBs. Now using ulink the hello world exe becomes 129_564 bytes. Bye, bearophile

Re: What can be done to reduce executable size?

On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote: On 12/16/11 1:12 AM, Jonathan M Davis wrote: Simply making it so that std.file is only imported in std.stdio with version(unittest) cut off _that_ much? Yah, but the matter is more complex. The issue is that std.file pulls

Re: What can be done to reduce executable size?

Am 16.12.2011, 10:15 Uhr, schrieb bearophile bearophileh...@lycos.com: Andrei Alexandrescu: Right now an executable starts at around 218KB, which includes druntime (gc, type info, the works). Importing std.stdio and using writeln() only adds a couple of KBs. Now using ulink the hello world

Re: What can be done to reduce executable size?

Am 16.12.2011, 14:52 Uhr, schrieb Trass3r u...@known.com: Am 16.12.2011, 10:15 Uhr, schrieb bearophile bearophileh...@lycos.com: Andrei Alexandrescu: Right now an executable starts at around 218KB, which includes druntime (gc, type info, the works). Importing std.stdio and using writeln()

Re: What can be done to reduce executable size?

On Friday, 16 December 2011 at 09:50:30 UTC, Jonathan M Davis wrote: Well, both std.datetime and core.time need static this() and can't not have it. Why are they necessary? It looks like it sets the time zone... wouldn't it work to put that into DateTime's regular constructor?

Re: What can be done to reduce executable size?

What I have in mind is if the timezone was something along the lines of a singleton property, so it still works the same way, except it is lazy loaded on first use. (if this is indeed the right static constructor!)

Re: What can be done to reduce executable size?

On Friday, December 16, 2011 16:16:53 Adam D. Ruppe wrote: What I have in mind is if the timezone was something along the lines of a singleton property, so it still works the same way, except it is lazy loaded on first use. (if this is indeed the right static constructor!) That would break

Re: What can be done to reduce executable size?

On Friday, 16 December 2011 at 16:35:27 UTC, Jonathan M Davis wrote: That would break purity, so no that doesn't work. The singletons are pure. I'm tempted to say just cast it away, since you aren't actually breaking purity in any meaningful way; the return value is always the same and it

Re: What can be done to reduce executable size?

Am 16.12.2011, 04:40 Uhr, schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: https://github.com/D-Programming-Language/phobos/commit/b7f42ec925fb1d64564d48ea419e201bfc65ed53 Yeah one could also use the new (function-)local imports. However, this also shows another problem common to C

Re: What can be done to reduce executable size?

Trass3r: Now using ulink the hello world exe becomes 129_564 bytes. What is its secret? Linkers use grey magic, as you know. And it doesn't use compression. Bye, bearophile

Re: What can be done to reduce executable size?

On 12/16/11 3:49 AM, Jonathan M Davis wrote: On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote: On 12/16/11 1:12 AM, Jonathan M Davis wrote: Simply making it so that std.file is only imported in std.stdio with version(unittest) cut off _that_ much? Yah, but the matter is more

Re: What can be done to reduce executable size?

On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote: On 12/16/11 3:49 AM, Jonathan M Davis wrote: On Friday, December 16, 2011 02:38:09 Andrei Alexandrescu wrote: On 12/16/11 1:12 AM, Jonathan M Davis wrote: Simply making it so that std.file is only imported in std.stdio with

Re: What can be done to reduce executable size?

On Dec 15, 2011, at 7:40 PM, Andrei Alexandrescu wrote: On 12/10/11 9:39 AM, Bane wrote: Short term and long term suggestions ? Anything we can do ? I heard it is some problem with linking dead code? import std.stdio; int main(){ writefln(Hello Bloat!); return 0; } dmd -release

Re: What can be done to reduce executable size?

On 12/16/11 12:40 PM, Jonathan M Davis wrote: On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote: I am pretty sure they don't need static this(). Only last night I removed static this() from core.time. I don't know how you could do that in core.time, since ticksPerSec and

Re: What can be done to reduce executable size?

On Dec 16, 2011, at 11:04 AM, Andrei Alexandrescu wrote: On 12/16/11 12:40 PM, Jonathan M Davis wrote: On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote: I am pretty sure they don't need static this(). Only last night I removed static this() from core.time. I don't know how

Re: What can be done to reduce executable size?

On Friday, December 16, 2011 11:07:14 Sean Kelly wrote: On Dec 16, 2011, at 11:04 AM, Andrei Alexandrescu wrote: On 12/16/11 12:40 PM, Jonathan M Davis wrote: On Friday, December 16, 2011 11:45:42 Andrei Alexandrescu wrote: I am pretty sure they don't need static this(). Only last night I

Re: What can be done to reduce executable size?

On 12/16/11 1:07 PM, Sean Kelly wrote: This is fine, but the whole point of static ctors in D is to eliminate all the stupid workarounds required to use statics in C++. I'd much rather we find a way to make the use of static ctors more efficient than give up on the feature. I agree, but then I

Re: What can be done to reduce executable size?

On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote: On 12/16/11 1:07 PM, Sean Kelly wrote: This is fine, but the whole point of static ctors in D is to eliminate all the stupid workarounds required to use statics in C++. I'd much rather we find a way to make the use of static ctors more

Re: What can be done to reduce executable size?

On 12/16/11 4:21 PM, Sean Kelly wrote: On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote: On 12/16/11 1:07 PM, Sean Kelly wrote: This is fine, but the whole point of static ctors in D is to eliminate all the stupid workarounds required to use statics in C++. I'd much rather we find a

Re: What can be done to reduce executable size?

On Dec 16, 2011, at 2:54 PM, Andrei Alexandrescu wrote: On 12/16/11 4:21 PM, Sean Kelly wrote: On Dec 16, 2011, at 12:26 PM, Andrei Alexandrescu wrote: On 12/16/11 1:07 PM, Sean Kelly wrote: This is fine, but the whole point of static ctors in D is to eliminate all the stupid workarounds

Re: What can be done to reduce executable size?

On 12/10/11 9:39 AM, Bane wrote: Short term and long term suggestions ? Anything we can do ? I heard it is some problem with linking dead code? import std.stdio; int main(){ writefln(Hello Bloat!); return 0; } dmd -release -O hello.d On Windows: v1.071 = 339 Kb v2.056 = 1017 Kb It looks

Re: What can be done to reduce executable size?

On Thursday, December 15, 2011 21:40:57 Andrei Alexandrescu wrote: On 12/10/11 9:39 AM, Bane wrote: Short term and long term suggestions ? Anything we can do ? I heard it is some problem with linking dead code? import std.stdio; int main(){ writefln(Hello Bloat!); return 0;

Re: What can be done to reduce executable size?

Martin Krejcirik: I don't know about D2, but for D1 it helps to recompile Phobos without -lib (use lib.exe, see win32.mak). What are the effects/disadvantages of doing this? Bye, bearophile

Re: What can be done to reduce executable size?

On 2011-12-14 12:47, bearophile wrote: Martin Krejcirik: I don't know about D2, but for D1 it helps to recompile Phobos without -lib (use lib.exe, see win32.mak). What are the effects/disadvantages of doing this? Bye, bearophile You need to explicitly invoke the tool that creates

Re: What can be done to reduce executable size?

On 10.12.2011 16:39, Bane wrote: Short term and long term suggestions ? Anything we can do ? I heard it is some problem with linking dead code? I don't know about D2, but for D1 it helps to recompile Phobos without -lib (use lib.exe, see win32.mak). Hello.d - 84k I'm attaching my makefiles,

Re: What can be done to reduce executable size?

On 2011-12-11 23:55, Jonathan M Davis wrote: On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote: Jacob Carlborg Wrote: As long as the runtime and standard library is statically linked the executables will be bigger than the corresponding C/C++ executable. I just want to say it's very

Re: What can be done to reduce executable size?

You can try with upx :) Il giorno lun, 12/12/2011 alle 14.42 +0100, Jacob Carlborg ha scritto: On 2011-12-11 23:55, Jonathan M Davis wrote: On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote: Jacob Carlborg Wrote: As long as the runtime and standard library is statically linked the

Re: What can be done to reduce executable size?

The symbol table. Probably you also had debug infos for phobos? By the way if I strip this, my executable is only 292K. On Sat, 10 Dec 2011 20:16:54 +0100, Trass3r u...@known.com wrote: import std.stdio; int main(){ writefln(Hello Bloat!); return 0; } dmd -release -O hello.d On

Re: What can be done to reduce executable size?

Am 12.12.2011, 20:33 Uhr, schrieb Martin Nowak d...@dawgfoto.de: The symbol table. Probably you also had debug infos for phobos? Possible. By the way if I strip this, my executable is only 292K. 32bits?

Re: What can be done to reduce executable size?

Trass3r u...@known.com wrote in message news:op.v6ai1yjc3ncmek@enigma... Right, but my point is, I could work around (I've gotten within inches of it!) it if simply Walter released a TINY part of snn.lib -- just a handful of tiny source files regarding the TLS-related stuff, EXE segment

Re: What can be done to reduce executable size?

On 2011-12-10 16:39, Bane wrote: Short term and long term suggestions ? Anything we can do ? I heard it is some problem with linking dead code? import std.stdio; int main(){ writefln(Hello Bloat!); return 0; } dmd -release -O hello.d On Windows: v1.071 = 339 Kb v2.056 = 1017 Kb It looks

Re: What can be done to reduce executable size?

Jacob Carlborg Wrote: As long as the runtime and standard library is statically linked the executables will be bigger than the corresponding C/C++ executable. I just want to say it's very important to me that static linking still just works very easily even if we start to offer dynamic

Re: What can be done to reduce executable size?

On Sunday, December 11, 2011 17:28:58 Adam Ruppe wrote: Jacob Carlborg Wrote: As long as the runtime and standard library is statically linked the executables will be bigger than the corresponding C/C++ executable. I just want to say it's very important to me that static linking still

Re: What can be done to reduce executable size?

Most definitely. I consider dynamic linking to be a necessary evil which should not be used unless you have to. I _much_ prefer having my programs completely self-contained. The less that they rely on in terms of external libraries the better. Sure, there are plenty of cases where dynamic

What can be done to reduce executable size?

Short term and long term suggestions ? Anything we can do ? I heard it is some problem with linking dead code? import std.stdio; int main(){ writefln(Hello Bloat!); return 0; } dmd -release -O hello.d On Windows: v1.071 = 339 Kb v2.056 = 1017 Kb It looks very ugly and might distract

Re: What can be done to reduce executable size?

On Windows: v1.071 = 339 Kb v2.056 = 1017 Kb v2.057b= 840 kb (upx --best = 151 kb)

Re: What can be done to reduce executable size?

Mirko Pilger Wrote: On Windows: v1.071 = 339 Kb v2.056 = 1017 Kb v2.057b= 840 kb (upx --best = 151 kb) That is improvement. 2.07 is not released yet ? And I don't think UPX is solution. It makes things look even worse, like too much makeup on ugly chick.

Re: What can be done to reduce executable size?

On 12/10/11 4:55 PM, Bane wrote: That is improvement. 2.07 is not released yet ? Yeah, 2.057 is still in beta (expect a release during the next few days, though). It has some Phobos/druntime changes geared specifically towards reducing executable size. David

Re: What can be done to reduce executable size?

I am dealing with scenario of large numbers of programs written in D placed on same host/1 installer, when it all sums up size does matters. Is it possible to move phobos or runtime to shared lib ? It would reduces code significantly.

Re: What can be done to reduce executable size?

Is it possible to move phobos or runtime to shared lib ? It would reduces code significantly.

Re: What can be done to reduce executable size?

Try using the unilink linker: ftp://ftp.styx.cabel.net/pub/UniLink/ Get ulnb0329.zip You have to configure ulink.cfg to this: -zsnn.lib -LC:\dmd\windows\lib -LC:\dm\lib -Go -zkernel32;advapi32;user32;wsock32;shell32;snn.lib -LC:\dmd2\windows\lib -Go Then linking is just: ulink file1.obj

Re: What can be done to reduce executable size?

Am 10.12.2011, 17:17 Uhr, schrieb Bane branimir.milosavlje...@gmail.com: Is it possible to move phobos or runtime to shared lib ? It would reduces code significantly. Theoretically but there are some hurdles (esp. regarding the runtime/gc). Some people have already tried this (on Linux of

  1   2   >