Bloat with std.(string.)format?

[Chris via Digitalmars-d-learn]

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.