www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5548] New: Efficient std.conv.to conversions

reply d-bugmail puremagic.com writes:
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



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: -------
Feb 08 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5548


Steven Schveighoffer <schveiguy yahoo.com> changed:

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



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: -------
Feb 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



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: -------
Jun 14 2012
prev sibling parent d-bugmail puremagic.com writes:
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                     |



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: -------
Nov 01 2013