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