On Thursday, 17 September 2015 at 12:49:03 UTC, John Colvin wrote:
On Thursday, 17 September 2015 at 10:53:17 UTC, Chris wrote:
On Thursday, 17 September 2015 at 10:33:44 UTC, John Colvin
wrote:
Some initial bloat is expected, format is pretty big
(although twice as big is a lot, unless your original code
was quite small?).
It was in a test program. Only a few lines. But it would still
add a lot of bloat in a program that uses it in different
modules, wouldn't it?
The upfront cost is paid only once per unique template
arguments per binary. So no, it doesn't scale badly there.
Inlining, on the other hand, will - roughly speaking - increase
binary sizes linearly with the number of calls. That's the cost
you pay for (hopefully) better performance.
The extra bloat per call is likely due to inlining. I would
hope that dmd would spot consecutive inlining of the same
function and merge them, but perhaps it doesn't.
You could certainly make a less feature complete
implementation of format that is smaller.
Don't know if it's worth the trouble.
I would say not worth it, unless you have a real problem with
binary sizes for an actual finished product. Even then, I'd say
you could get bigger, easier gains by messing around with
-fvisibility settings, --gc-sections, strip etc. on GDC and LDC
Have you tried with ldc or gdc. In particular, have you tried
using ldc with --gc-sections on linux?
Not yet. GDC and LDC always lag behind (this time
considerably), so I'm usually stuck with DMD for development.
That's a shame.
https://github.com/ldc-developers/ldc/releases/tag/v0.16.0-alpha3 is at 2.067.1, is that not up-to-date enough?
Thanks.
That's up to date enough now. Is it stable, though? For version
2.067.1 it took a long time this time. Maybe we should focus some
of our efforts on LDC and GCD being up to date faster.
