So I was using the Lazarus IDE the other day, and i thought to myself, what if i create an application with only a button in it. well it was easy enough to do. but behold I saw the executable and it was 14 MB, and I said 'well damn.' It seems to me that pascal does not do lazy inclusion when it comes to components of Lcl apart from pre-compiler directives.

I noticed some includes in d are inside of functions.

void foo() {
 import thingIneed:subfoo;
 subfoo();
}

would this allow people to use a large library like LCL but with much smaller executables?

On Sunday, 1 March 2015 at 20:41:30 UTC, Taylor Hillegeist wrote:
> So I was using the Lazarus IDE the other day, and i thought to myself, what if i create an application with only a button in it. well it was easy enough to do. but behold I saw the executable and it was 14 MB, and I said 'well damn.' It seems to me that pascal does not do lazy inclusion when it comes to components of Lcl apart from pre-compiler directives.
>
> I noticed some includes in d are inside of functions.
>
> void foo() {
>  import thingIneed:subfoo;
>  subfoo();
> }
>
> would this allow people to use a large library like LCL but with much smaller executables?

Sounds like you did a debug build.
Read this: http://wiki.freepascal.org/Size_Matters

On Sunday, 1 March 2015 at 20:41:30 UTC, Taylor Hillegeist wrote:
> So I was using the Lazarus IDE the other day, and i thought to myself, what if i create an application with only a button in it. well it was easy enough to do. but behold I saw the executable and it was 14 MB, and I said 'well damn.' It seems to me that pascal does not do lazy inclusion when it comes to components of Lcl apart from pre-compiler directives.
>
> I noticed some includes in d are inside of functions.
>
> void foo() {
>  import thingIneed:subfoo;
>  subfoo();
> }
>
> would this allow people to use a large library like LCL but with much smaller executables?

Turn off the debug build - it's then only a few meg...

-<Mike>-

On Sunday, 1 March 2015 at 21:39:08 UTC, Mike James wrote:
> On Sunday, 1 March 2015 at 20:41:30 UTC, Taylor Hillegeist wrote:
>> So I was using the Lazarus IDE the other day, and i thought to myself, what if i create an application with only a button in it. well it was easy enough to do. but behold I saw the executable and it was 14 MB, and I said 'well damn.' It seems to me that pascal does not do lazy inclusion when it comes to components of Lcl apart from pre-compiler directives.
>>
>> I noticed some includes in d are inside of functions.
>>
>> void foo() {
>> import thingIneed:subfoo;
>> subfoo();
>> }
>>
>> would this allow people to use a large library like LCL but with much smaller executables?
>
> Turn off the debug build - it's then only a few meg...
>
> -<Mike>-
Yes, the debug does help quite a lot. I like the idea of LCL one widget front end so you don't have to worry as much about deployment. but i haven't found a good all static cross platform solution for d.

so far my favorite GUI libraries so far are:

xwt: mono
LCL: Object Pascal

I like the write once compile anywhere of Lazarus. And I think it makes more sense to target the platforms native widget library than to force users to install one or package the whole library with your executable.

But still the question was about smaller executable when compiling d code. The linker needs to know which .o files to include, the pascal notation is basically:

uses
 thisBigoleThing, ThisOtherBigOleThing, AndMeToo;

I assume the linker just auto-magically includes the entire thing even if your only using a single function or value from each. Then again perhaps I am wrong.

On Sun, 01 Mar 2015 22:40:28 +0000, Taylor Hillegeist wrote:

> But still the question was about smaller executable when compiling d code. The linker needs to know which .o files to include, the pascal notation is basically:
> 
> uses
>   thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
> 
> I assume the linker just auto-magically includes the entire thing even if your only using a single function or value from each. Then again perhaps I am wrong.

FreePascal learnt the "smart linking" trick years ago, so only actually used functions ends in linked binary. but LCL is very big library, and FPC can't drop out unused virtual methods, so resulting binaries are big.

with D we have the same situation, maybe even worse due to template instantiation. compiler is able to merge identical template instanses, but... empty `void main () {}` is ~200 KB in D (GNU/Linux, x86). adding simple `import std.stdio : writeln;` increases binary size to ~300 KB. and adding `writeln("hello!");` increases binary size to ~350 KB.

D binaries are big. ;-)

On Monday, 2 March 2015 at 01:22:58 UTC, ketmar wrote:
> On Sun, 01 Mar 2015 22:40:28 +0000, Taylor Hillegeist wrote:
>
>> But still the question was about smaller executable when compiling d
>> code. The linker needs to know which .o files to include, the pascal
>> notation is basically:
>> 
>> uses
>>   thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
>> 
>> I assume the linker just auto-magically includes the entire thing even
>> if your only using a single function or value from each. Then again
>> perhaps I am wrong.
>
> FreePascal learnt the "smart linking" trick years ago, so only actually
> used functions ends in linked binary. but LCL is very big library, and FPC
> can't drop out unused virtual methods, so resulting binaries are big.
>
> with D we have the same situation, maybe even worse due to template
> instantiation. compiler is able to merge identical template instanses,
> but... empty `void main () {}` is ~200 KB in D (GNU/Linux, x86). adding
> simple `import std.stdio : writeln;` increases binary size to ~300 KB.
> and adding `writeln("hello!");` increases binary size to ~350 KB.
>
> D binaries are big. ;-)

LDC + dynamic linking gets pretty tiny binaries, C binaries aren't all that small if you static link in glibc ;)

On Monday, 2 March 2015 at 01:22:58 UTC, ketmar wrote:
> On Sun, 01 Mar 2015 22:40:28 +0000, Taylor Hillegeist wrote:
>
>> But still the question was about smaller executable when compiling d
>> code. The linker needs to know which .o files to include, the pascal
>> notation is basically:
>> 
>> uses
>>   thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
>> 
>> I assume the linker just auto-magically includes the entire thing even
>> if your only using a single function or value from each. Then again
>> perhaps I am wrong.
>
> FreePascal learnt the "smart linking" trick years ago, so only actually
> used functions ends in linked binary. but LCL is very big library, and FPC
> can't drop out unused virtual methods, so resulting binaries are big.
>
> with D we have the same situation, maybe even worse due to template
> instantiation. compiler is able to merge identical template instanses,
> but... empty `void main () {}` is ~200 KB in D (GNU/Linux, x86). adding
> simple `import std.stdio : writeln;` increases binary size to ~300 KB.
> and adding `writeln("hello!");` increases binary size to ~350 KB.
>
> D binaries are big. ;-)

That seems like alot of KB for just a little bit of code. I wasn't aware that void main(){} was anything but entry pointer...

 ;; pseudo-assembly-language
 ;; main(argc, argv, envp); call

 push envp  ;; rightmost argument
 push argv  ;;
 push argc  ;; leftmost argument ends up on top of stack

 call main

I guess I'm confused about what is in there and why?

On Monday, 2 March 2015 at 03:51:45 UTC, Taylor Hillegeist wrote:
> On Monday, 2 March 2015 at 01:22:58 UTC, ketmar wrote:
>> On Sun, 01 Mar 2015 22:40:28 +0000, Taylor Hillegeist wrote:
>>
>>> But still the question was about smaller executable when compiling d
>>> code. The linker needs to know which .o files to include, the pascal
>>> notation is basically:
>>> 
>>> uses
>>>  thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
>>> 
>>> I assume the linker just auto-magically includes the entire thing even
>>> if your only using a single function or value from each. Then again
>>> perhaps I am wrong.
>>
>> FreePascal learnt the "smart linking" trick years ago, so only actually
>> used functions ends in linked binary. but LCL is very big library, and FPC
>> can't drop out unused virtual methods, so resulting binaries are big.
>>
>> with D we have the same situation, maybe even worse due to template
>> instantiation. compiler is able to merge identical template instanses,
>> but... empty `void main () {}` is ~200 KB in D (GNU/Linux, x86). adding
>> simple `import std.stdio : writeln;` increases binary size to ~300 KB.
>> and adding `writeln("hello!");` increases binary size to ~350 KB.
>>
>> D binaries are big. ;-)
>
> That seems like alot of KB for just a little bit of code. I wasn't aware that void main(){} was anything but entry pointer...
>
>  ;; pseudo-assembly-language
>  ;; main(argc, argv, envp); call
>
>  push envp  ;; rightmost argument
>  push argv  ;;
>  push argc  ;; leftmost argument ends up on top of stack
>
>  call main
>
> I guess I'm confused about what is in there and why?

Even C startup code is more than just that.

You need to set up the runtime, initialize global variables, run functions marked to execute before main.

--
Paulo

On Mon, 02 Mar 2015 03:51:43 +0000, Taylor Hillegeist wrote:

> That seems like alot of KB for just a little bit of code. I wasn't aware that void main(){} was anything but entry pointer...
> 
>   ;; pseudo-assembly-language ;; main(argc, argv, envp); call
> 
>   push envp  ;; rightmost argument push argv  ;;
>   push argc  ;; leftmost argument ends up on top of stack
> 
>   call main
> 
> I guess I'm confused about what is in there and why?

you need runtime to support all D features. try to link static C code, for example. typical C binary is cheating, using system libc as dynamic library. we can do this for D too (at least for dmd), but there is no sense, as there is no system that is bundled with libphobos2.so ;-)