[swift-users] Optimal String conversion to/from UTF-8 w/o null-termination?

[Kelvin Ma]

doesn’t the compiler like to optimize the loop out of the benchmarking
code? i’ve always had a hard time writing benchmarks in Swift

On Fri, Nov 3, 2017 at 7:10 PM, Ryan Walklin via swift-users <
swift-users at swift.org> wrote:

> Why not just profile it? Set up a loop of 100,000 or so with each method
> and time it.
>
> Ryan
>
> > On 4 Nov 2017, at 6:42 am, Jens Alfke via swift-users <
> swift-users at swift.org> wrote:
> >
> > I’m working with a C API that represents strings as UTF-8 data tagged
> with a length but **without a trailing NUL byte**. In other words, its
> string type is basically a tuple {const char*, size_t}. I need to convert
> this representation to and from Swift 4 strings.
> >
> > This needs to be efficient, as these calls will occur in some areas of
> my project that are known to be performance-critical. (Equivalent
> conversions in my Obj-C code have already shown up as hot-spots and been
> carefully optimized.)
> >
> > For String-to-UTF-8, I’m using String.withCString():
> >    _ = str.withCString { bytes in c_function(bytes, strlen(bytes)) }
> > An alternative is
> >    let bytes = [UInt8](str.utf8)
> >    c_function(&bytes, bytes.count)
> > Any idea which of these is more optimal? The former has to call strlen,
> but I suspect the latter may incur more heap allocation.
> >
> > For UTF-8-to-String I use this, where `stringPointer` is an
> UnsafeRawPointer and stringLen is an Int:
> >    let data = Data(bytes: stringPointer, count: stringLen)
> >    return String(data: data, encoding: String.Encoding.utf8)
> > I’m unhappy about this because it incurs both heap allocation and
> copying the string bytes. But Data doesn’t seem to have the “noCopy”
> options that NSData does. Any way to pass the bytes directly to String
> without an intermediate copy?
> >
> > —Jens
> >
> > PS: I’m aware this is an FAQ, but I’ve already put in time searching.
> Most of the hits are obsolete because the damn String API keeps changing,
> or else they assume NUL-terminated C strings; and the remainder don’t
> consider performance.
> > _______________________________________________
> > swift-users mailing list
> > swift-users at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-users
>
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20171106/49f40db6/attachment.html>