On 04/21/12 12:24, Marco Leise wrote:
> At first I confused your project with GtkD. I'll take a look at it, to see
> how it compares. Many examples for Gtk use C code, and I end up looking for
> the correct GtkD class that offers the function. Otherwise I quite like the
> classical inheritance that is possible with GtkD, whereas you use the "alias
> this" trick, which is fair enough. Also you can bind events like onExpose
> naturally to class methods in GtkD. There is no data pointer involved.
Hmm, some sugar is likely possible for things like signal callbacks;
i'll think about it.
> On the other hand small executables are my cup of tea. I've compiled a small
> Haskell Gtk application, that weighted ~10 MB (stripped) and the same program
> in D using GtkD was 3.4 MB in size. Let's see...
>
"example_gtk", which is probably the smallest /useful/ GTK2 app is 315K
here (32-bit x86 linux), after commenting out the _dumpObj(event) call.
(I wonder how large an equivalent gtkD version would be... But, as i care
more about /runtime/ efficiency, it's not a very interesting metric)
If you care about executable sizes, some GDC specific notes:
- compile with "-ffunction-sections -fdata-sections -Wl,--gc-sections"
Things like std.bitmanip unconditionally emit functions, which will
be rarely used, but bloat the executable.
- do *not* compile with "-Wl,--export-dynamic"
This option will slow down linking, while enabling better backtraces;
unfortunately it will also prevent the gc-sections optimizations above
from working.
- use '-frelease -fno-bounds-check'
- use '-flto'
- do not use '-g' together with '-flto' for the final executable linking
GCC (4.6) bug, can result in ICE.
- strip the executable
artur
