Bloat with std.(string.)format?

[John Colvin via Digitalmars-d-learn]

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?