fix Issue 20566 - std.sformat should avoid allocating memory when pri…

[rainers]

…nting floating point values

use stack allocated buffers as long as the required precision is within reasonable values

[dlang-bot]

Thanks for your pull request, @rainers!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20566	enhancement	std.sformat should avoid allocating memory when printing floating point values

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + phobos#7393"

[ghost]

I like your idea of having a fixed length buffer for the "small" numbers, which is replaced in case it doesn't fit by a gc allocated buffer. This won't produce wrong results, but should be faster and without gc for "small" numbers.

The timing of this PR doesn't fit in my plans though. I'm currently waiting on PR #7264 to be merged. After that my plan was to add support for the %g qualifier, which I don't think is much of a problem as it's essentially deciding between %f and %e which are allready in there. Next I'd like to make the whole thing CTFEable. The PR for this is allready written for %e, %f and %a.

Now your PR would interfere with this process and I would have to rewrite and test a lot of code and remove several merge conflicts. So I would be happy if this could be postponed for a while.

After it's CTFEable I'm open for this sort of improvement. I allready though about using fixed length arrays for "smaller" numbers, but only for speed reasons, not for avoiding gc (I wasn't aware of this) and I had no idea how to mix this without code duplication, so I'm happy about your solution.

And I also remember that I used byte instead of char for speed reasons, but it's too long ago, to remember the details. I will have to recompare this.

[rainers]

I like your idea of having a fixed length buffer for the "small" numbers, which is replaced in case it doesn't fit by a gc allocated buffer. This won't produce wrong results, but should be faster and without gc for "small" numbers.

Pedantically, no allocations should happen for std.sformat (see also https://issues.dlang.org/show_bug.cgi?id=13055), but correctly clipping the buffer would mean a very different way to write to the output. Some estimates for character length are not good enough for this. @nogc is currently impossible due to exceptions being allocated, too.

The timing of this PR doesn't fit in my plans though. I'm currently waiting on PR #7264 to be merged. After that my plan was to add support for the %g qualifier, which I don't think is much of a problem as it's essentially deciding between %f and %e which are allready in there. Next I'd like to make the whole thing CTFEable. The PR for this is allready written for %e, %f and %a.

Now your PR would interfere with this process and I would have to rewrite and test a lot of code and remove several merge conflicts. So I would be happy if this could be postponed for a while.

I don't think merging will be very difficult, as most changes are adding buf[] to the tests, and most of these seem to remain unchanged in your other PR.

After it's CTFEable I'm open for this sort of improvement. I allready though about using fixed length arrays for "smaller" numbers, but only for speed reasons, not for avoiding gc (I wasn't aware of this) and I had no idea how to mix this without code duplication, so I'm happy about your solution.

CTFEability would also be nice in druntime, as some function use sprintf there, too (e.g. core.demangle for float template arguments).

And I also remember that I used byte instead of char for speed reasons, but it's too long ago, to remember the details. I will have to recompare this.

I think it might only make a difference if you iterate over a buffer with foreach, but I don't see this happening here.

[thewilsonator]

Is this good to go?

[rainers]

Is this good to go?

IMO, yes. @berni44 had some reservations regarding merging with #7264, but I don't think it will be too bad. Not allocating will help make his performance improvements shine, too.