www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Would Lcl be better if it was in D?

reply "Taylor Hillegeist" <taylorh140 gmail.com> writes:
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?
Mar 01 2015
next sibling parent "Jacques =?UTF-8?B?TcO8bGxlciI=?= <jacques.mueller gmx.de> writes:
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
Mar 01 2015
prev sibling parent reply "Mike James" <foo bar.com> writes:
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>-
Mar 01 2015
parent reply "Taylor Hillegeist" <taylorh140 gmail.com> writes:
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.
Mar 01 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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:
=20
 uses
   thisBigoleThing, ThisOtherBigOleThing, AndMeToo;
=20
 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=20
used functions ends in linked binary. but LCL is very big library, and FPC=20
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=20
instantiation. compiler is able to merge identical template instanses,=20
but... empty `void main () {}` is ~200 KB in D (GNU/Linux, x86). adding=20
simple `import std.stdio : writeln;` increases binary size to ~300 KB.=20
and adding `writeln("hello!");` increases binary size to ~350 KB.

D binaries are big. ;-)=
Mar 01 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
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 ;)
Mar 01 2015
prev sibling parent reply "Taylor Hillegeist" <taylorh140 gmail.com> writes:
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?
Mar 01 2015
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Mar 01 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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...
=20
   ;; pseudo-assembly-language ;; main(argc, argv, envp); call
=20
   push envp  ;; rightmost argument push argv  ;;
   push argc  ;; leftmost argument ends up on top of stack
=20
   call main
=20
 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,=20
for example. typical C binary is cheating, using system libc as dynamic=20
library. we can do this for D too (at least for dmd), but there is no=20
sense, as there is no system that is bundled with libphobos2.so ;-)=
Mar 02 2015