std.conv.to!string(float) Is too heavy

Hipreme msnmancini at hotmail.com
Tue Oct 12 18:06:53 UTC 2021


On Tuesday, 12 October 2021 at 16:04:49 UTC, user1234 wrote:
> On Tuesday, 12 October 2021 at 14:47:21 UTC, Hipreme wrote:
>> I have wrote a simple hello world using std.conv:
>>
>>
>> ```
>> import std.conv:to;
>> import std.stdio;
>>
>> export void MAIN(float b)
>> {
>> 	writeln("Hello World " ~ to!string(b));
>> }
>> ```
>>
>> Building that with dmd app.d -lib creates 500KB lib
>> With `-g`, it goes up to 800KB
>>
>> Using ldc, the build time goes up by 2 times.
>>
>> if you simply change from `float b` to `int b`, the lib goes 
>> down from 500KB to 60KB.
>
> You compare apples and oranges. Convertion from integer types 
> to string is trivial, converting float types to string is not.
>
> That being said there's some room for improvment. `writeln` of 
> a `float` will take the same path as `format(%f, v)`, which 
> contains the code to format float in every possible way, as the 
> specifier is not known at compile time, and finally only a 
> small part of the bloat generated is executed.
>
> This is bit strange, as for writeln, the specifier is known at 
> compile time.
>
>> The build times decreases by almost 10x (must check), but I 
>> can feel that anyway.
>>
>> Using std.conv greatly degrades a modularized workflow, by 
>> increasing a lot of build time and binary size. I needed 
>> implementing my own to! function to get a much better build 
>> time for my program.



Lot of people has implemented float to string conversion without 
requiring 500KB.
I really don't think I need all that 'runtime speed' nor 'ultra 
precision', it would be great if we had some compiler flag to 
stop this template bloating thing for we can choose for build 
speed instead.

Yea, writeln does cause 500KB requirement for `floats` and 
`struct`s too (without float members). I guess it is much more 
template hell than any other thing.

Yea, I forced it for not inlining my number, because, that's the 
point, most of the time you won't be inlining a number.

I have like, more than 8 modules, some depending on each other, 
this build time can increase a LOT linking time and the compile 
time. Usually, the modularized workflow should make things faster 
and reuse already compiled code. If the stdlib itself weights so 
much, the modularized workflow will start to feel useless


More information about the Digitalmars-d mailing list