http://d.puremagic.com/issues/show_bug.cgi?id=5548

           Summary: Efficient std.conv.to conversions
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody@puremagic.com
        ReportedBy: tomeksowi@gmail.com


--- Comment #0 from Tomasz Sowiński <tomeksowi@gmail.com> 2011-02-08 12:47:58 PST ---
Currently most to!T conversions allocate behind the scenes. I propose that the conversions where T is dynamically sized (like an array) get a speedy overload of the form:

void to(T, S, O)(S source, O output) if (isOutputRange!(O, T));

Example: to!string(9234820934, appender);

For further investigation: consider assuming the output range to be buffered.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5548


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #1 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-02-08 12:52:10 PST ---
Do we not have the functionality for this (at least for strings) in std.format?

Are there use cases for this beyond strings?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5548


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #2 from Kenji Hara <k.hara.pg@gmail.com> 2012-06-14 02:33:25 PDT ---
I agree with Steven. If you want to represent objects with output range of characters, you can use std.format.formatValue family directly.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=5548


Orvid King <blah38621@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |blah38621@gmail.com
         Resolution|WONTFIX                     |


--- Comment #3 from Orvid King <blah38621@gmail.com> 2013-11-01 08:26:19 PDT ---
After a bit of testing, std.format.fomatValue is not a valid alternative to having std.conv.to provide overloads that accept an output buffer. The reason for this is simple, the following code is 3x slower than simply using to!string(int):


auto toStr = benchmark!(() {
    import std.format;
    import std.range : Appender;

    auto ret = Appender!string();
    auto fmt = FormatSpec!char("%s");
    ret.reserve(4096);
    for (auto i = 0; i < ObjectCount * 11; i++)
    {
        ret.formatValue(i, fmt);
        ret.clear();
    }
})(1);

writefln("Took %s ms (%s) to serialize 100k SimpleObjects with an average
payload of %s bytes (%s).", res[0].msecs, toStr[0].msecs,
cast(real)totalPayload / ObjectCount, totalPayload);


In my tests where ObjectCount was 100k, it takes 400ms for to!string(int) to create all the strings, and 1100ms for formatValue to do the same. formattedWrite is even worse, 1500ms. In my current implementation of a dynamic JSON (de)serializer, more than half of my time is eaten up by converting integers to strings when performing deserialization. I use a pre-allocated output range as the destination, so I know I'm not doing any allocations within my code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------