Allow creating String from Memory{UInt8} with a given length

[quinnj]

With String(::Vector{UInt8}), we could always resize! the bytes before truncating and returning the String. With Memory{UInt8}, however, we obviously can't resize!. jl_genericmemory_to_string, however, does already take a length argument for how many bytes to use in the Memory to create the string, even if it still truncates the entire Memory to 0 bytes.

So the request here is that we provide something like String(m::Memory{UInt8}, len=length(m)), even though that feels a little weird to have 2 arguments to the String constructor like that. I thought of maybe using unsafe_string(m, len) for this, but it's not really unsafe and the current unsafe_ methods only take pointers.

Open to other suggestions here. I'm certainly not an expert in all the new memory machinery, so maybe I'm missing something more obvious here where it's trivial (and part of the public API) to easily get a "view" of a memory for a given length.

[oscardssmith]

Is the constructor you are proposing a copying constructor? If not, how is this intended to work?

[quinnj]

The intention is that even if I have a Memory{UInt8} of size 10, if I wanted to create a String(m, 5), then only the first 5 bytes of m would be used to create the String. It would have the same semantics as String(m) currently does (non-copying, truncates the memory), you would just be able to not use the full memory if desired.

My original point is that you can currently achieve this with Vector{UInt8} by resize!ing the vector down before calling String(v), but resize! (obviously) doesnt' apply to Memory.

[vtjnash]

I thought you could do this already by wrapping in an Array then making the String from that and letting inlining do its thing

[oscardssmith]

looking through the code, you can do this. as @vtjnash said. That said, it's almost always a bad idea to call String on a regular Memory (or Array) as opposed to a Base.StringMemory (Base.StringVector), since at that point you are just getting a copying constructor (jl_pchar_to_string) in C which will be strictly worse than doing the conversion in Julia.

[quinnj]

Yeah, that's why I want to make sure jl_genericmemory_to_string is used. In my use-case, I have a JSON with escapes that I'm going to unescape and convert to a string. So I allocate a Memory the same size as the escaped json string, do the unescaping to the Memory, then I want to make a String out of just the bytes I ended up writing to the Memory. I recognize there will be a few "trailing" bytes leftover, but I allows for not having to do another pass over the string just to figure out what the actual final unescaped String size will be.

I guess now that I think about, I could potentially keep track of how many escapes are encountered during the 1st pass in order to know what the final output size would be and then avoid the need to resize the memory. Maybe I'll play around if that's possible.

[nhz2]

I think it will usually be just as fast to use unsafe_string

using BenchmarkTools

tostr1(m::Memory{UInt8}, slen) = ccall(:jl_genericmemory_to_string, Ref{String}, (Any, Int), m, slen)
tostr2(m::Memory{UInt8}, slen) = String(view(m, 1:slen))
function tostr3(m::Memory{UInt8}, slen)
    cconv_m = Base.cconvert(Ptr{UInt8}, m)
    GC.@preserve cconv_m unsafe_string(Base.unsafe_convert(Ptr{UInt8}, cconv_m), slen)
end

@btime tostr1(m, 5) setup=(m=Memory{UInt8}(undef, 10); m .= 0x61;)
@btime tostr2(m, 5) setup=(m=Memory{UInt8}(undef, 10); m .= 0x61;)
@btime tostr3(m, 5) setup=(m=Memory{UInt8}(undef, 10); m .= 0x61;)

Results are:
tostr1: 7.663 ns (1 allocation: 24 bytes)
tostr2: 12.326 ns (2 allocations: 56 bytes)
tostr3: 6.901 ns (1 allocation: 24 bytes)

[quinnj]

That's.......fine, but it's different operations. I don't quite follow the allocation + bytes numbers in your example, but I would expect tostr1 to "only" allocate the String container, while pointing to the existing memory bytes, while tostr3 is allocating a String and the bytes to copy from the memory. Maybe I'm not understanding some low-level allocation machinery here though. Kind of implied in the original request here is that I already have some memory allocated that I want to turn into a String without copying.

[Seelengrab]

One concern with this non-copying behavior is that such a generic API is very easy to misuse - it's very easy to accidentally end up with two objects referring to the same underlying memory. I think this is what makes the operation unsafe_. How do we ensure that there's no aliasing? This is not an issue for the method taking a Vector, because there the String can take ownership of the internal Memory (by replacing the one internal to the vector with a new one).

[nhz2]

Yes, in my example, all three tostr* functions have an extra allocation and copy.

Maybe this is more what you want.

using BenchmarkTools

function foo1(n, slen)
    m = Base.StringMemory(n)
    for i in 1:slen
        @inbounds m[i] = i%UInt8
    end
    String(Base.wrap(Array, m, slen))
end

function foo2(n, slen)
    io = IOBuffer(;sizehint=n)
    truncate(io, n)
    m = take!(io)
    for i in 1:slen
        @inbounds m[i] = i%UInt8
    end
    resize!(m, slen)
    String(m)
end

function foo3(n, slen)
    m = Base.Memory{UInt8}(undef, n)
    for i in 1:slen
        @inbounds m[i] = i%UInt8
    end
    cconv_m = Base.cconvert(Ptr{UInt8}, m)
    GC.@preserve cconv_m unsafe_string(Base.unsafe_convert(Ptr{UInt8}, cconv_m), slen)
end

@btime foo1(10000, 5000);
@btime foo2(10000, 5000);
@btime foo3(10000, 5000);

foo2, and foo3 use only public functions. foo1 uses non-public functions wrap and StringMemory.

On Julia 1.11.5 I get:
foo1: 196.814 ns (2 allocations: 9.91 KiB)
foo2: 482.531 ns (4 allocations: 10.00 KiB)
foo3: 379.971 ns (3 allocations: 14.85 KiB)

On Julia 1.12.0-beta3 I get:
foo1: 200.118 ns (2 allocations: 9.91 KiB)
foo2: 421.854 ns (6 allocations: 37.09 KiB)
foo3: 380.030 ns (3 allocations: 14.85 KiB)

I have no idea why the allocations of foo2 jumped from 10 KiB to 37 KiB in 1.12, but I don't think there is a public way to do what you want that is reasonably performant.

It might be better to make a custom type and not worry about what kind of internal machinery is used to make Strings:

struct MyString
    m::Memory{UInt8}
    slen::Int
end

function foo4(n, slen)
    m = Base.Memory{UInt8}(undef, n)
    for i in 1:slen
        @inbounds m[i] = i%UInt8
    end
    MyString(m, slen)
end

@btime foo4(10000, 5000);

193.461 ns (2 allocations: 9.85 KiB)