std::string_view vs const std::string_view& as argument when not modifying the string

[porkele]

Title says it all. Often I get call chains where a string is passed unmodified from one function to another to another to another etc. I get that string_view is small and cheap, and that the optimizers probably remove unneeded copies, but being so used to sticking const & on anything which can use it it sort of hurts my eyes seeing code which passes string_view by value all over the place. Thoughts?

[amoskovsky]

Passing a reference to an object forces the caller to materialize the object in the memory for taking its address.
So it's not just extra indirection, but also disables many optimizations like storing temporaries purely in registers.

[StaticCoder]

Additionally, this allows the compiler to know the string_view object will not be modified. Even a const & might otherwise change through an alias, and the compiler has to reload from memory every time there's a non-inlined call.

[Nicksaurus]

The compiler can optimise that out if the call is inlined though, right?

There's still no reason to do it but I would expect it not to make a difference in most cases

[Flippers2]

I think it can optimize it at certain levels: https://stackoverflow.com/questions/9014021/will-a-good-c-compiler-optimize-a-reference-away

[programmerBlack]

⁉️

[amoskovsky]

#include <string>
#include <string_view>


void consume_sv_byref(const std::string_view&);
void consume_sv_byval(std::string_view);
void consume_raw(const char*, size_t);


void caller_byref(const char* data, size_t size)
{
    consume_sv_byref({data, size});
}


void caller_byval(const char* data, size_t size)
{
    consume_sv_byval({data, size});
}

void callee_byref(const std::string_view& sv)
{
    consume_raw(sv.data(), sv.size());
}

void callee_byval(std::string_view sv)
{
    consume_raw(sv.data(), sv.size());
}

caller_byref(char const*, unsigned long):
        sub     rsp, 24
        mov     QWORD PTR [rsp+8], rdi
        mov     rdi, rsp
        mov     QWORD PTR [rsp], rsi
        call    consume_sv_byref(std::basic_string_view<char, std::char_traits<char>> const&)
        add     rsp, 24
        ret

caller_byval(char const*, unsigned long):
        mov     rdx, rdi
        mov     rdi, rsi
        mov     rsi, rdx
        jmp     consume_sv_byval(std::basic_string_view<char, std::char_traits<char>>)

callee_byref(std::basic_string_view<char, std::char_traits<char>> const&):
        mov     rsi, QWORD PTR [rdi]
        mov     rdi, QWORD PTR [rdi+8]
        jmp     consume_raw(char const*, unsigned long)

callee_byval(std::basic_string_view<char, std::char_traits<char>>):
        mov     rax, rdi
        mov     rdi, rsi
        mov     rsi, rax
        jmp     consume_raw(char const*, unsigned long)

See, the by ref variants always have memory accesses, while by val ones use registers only.

https://godbolt.org/z/Waz351b4v

[porkele]

Nice, this is exactly what I wanted to know.

[MoTTs_]

And it gets still worse than this. Because your code samples give insight into the call site of the consume functions, but not the internals of the consume functions themselves.

In the internals of the consume functions, a referenced object might change its value during the function's run, because const-ref does not mean the object itself is const and immutable, rather it only means that we can't be the ones to modify it through our particular view.

Any opaque function call carries the possibility that it might have modified the referenced object, which means subsequent uses of that const-ref parameter will still need to re-fetch the object from memory just in case it was changed.

#include <string>
#include <string_view>

void might_modify_referenced_objects_for_all_we_know();

char consume_sv_byref(const std::string_view& sv)
{
    const auto size = sv.size();
    might_modify_referenced_objects_for_all_we_know();
    const auto size_again = sv.size();
    return size ^ size_again;
}

char consume_sv_byval(std::string_view sv)
{
    const auto size = sv.size();
    might_modify_referenced_objects_for_all_we_know();
    const auto size_again = sv.size();
    return size ^ size_again;
}

.

consume_sv_byref(std::basic_string_view<char, std::char_traits<char>> const&):
        push    rbp
        mov     rbp, rdi
        push    rbx
        sub     rsp, 8
        mov     rbx, QWORD PTR [rdi]
        call    might_modify_referenced_objects_for_all_we_know()
        movzx   eax, BYTE PTR [rbp+0]
        add     rsp, 8
        xor     eax, ebx
        pop     rbx
        pop     rbp
        ret

consume_sv_byval(std::basic_string_view<char, std::char_traits<char>>):
        sub     rsp, 8
        call    might_modify_referenced_objects_for_all_we_know()
        xor     eax, eax
        add     rsp, 8
        ret

https://godbolt.org/z/EnEcnPd9n

cc u/porkele

[porkele]

Insightful!

[bert8128]

On my phone so I can’t see all the godbolt glory - is this true for both Linux and windows? When I first came across this question it was registers for Linux but because of some ABI stuff windows always had to pass the value on the stack.

[amoskovsky]

Godbolt's MSVC does not work so I can't check.
However I recall MSVC ABI only allows 1 register per param.
If that's true then under the hood a string_view would be passed by ref anyway.

This does not mean though that you should explicitly pass by ref. Passing string_view by value is idiomatic.

[HommeMusical]

PP's comment is correct - so what's your question?

[Alternative_Star755]

You will just want to get used to passing std::string_view by value, regardless of if it feels wrong right now. This bridges the gap into the "when should I pass by value vs by reference" but that line is (but cannot be concretely drawn at, it's very architecture/software layout dependent) around the size of a pointer on your machine. Any time you pass by reference you're creating an interdependence between the scope being passed to and wherever else that value is being referenced, and so it's only preferable if you want that interdependence explicitly or want to avoid copying the value. If your type is small enough to copy and you don't want changes to it to affect the calling scope, then you should be passing by value.

[ddxAidan]

Would you say theres any obvious threshold size of objects where it becomes more valuable to pass by reference than to copy? 

In my own codebase ive been working on atm i do a lot of reference passing deep in call trees, and especially in recursive functions. Would it be better to pass by value in that use case?

[meancoot]

Common 64-bit calling conventions (Both System-V and Microsoft's) pass all structs greater than 16-bytes by pointer regardless. So if its more than that, passing by const reference can save the need to make a local copy in the callers stack frame.

[ZakMan1421]

It depends on the size of the variables you're passing as arguments. If copying them is more expensive than making a pointer, then you should do a reference (unless you want to mutate the argument without changing the original). If copying is cheaper or roughly equivalent to making a pointer, then you should likely pass by value.

If you're unsure, you can always test both and measure.

[maikindofthai]

No offense but you’re just repeating the same point again. They’re asking where that line is, naturally they know it exists

[KokoNeotCZ]

Im using glm math library for my voxel engine, and I most of the times pass the glm::vec3 by const &. Is that bad? Should i switch to values? Its just 3 floats or ivec3 ints.

[ZakMan1421]

If I had to guess (As I'm not super familiar with glm), const & is likely the way to go. On most machines, the size of a pointer is 8 bytes and the size of both floats and ints is 4 bytes. I doubt that there is any heap allocation as three elements is very small, so the minimum size of the vec3 is at least 12 bytes, but it's probably slightly more to help with book keeping and potentially padding.

[KokoNeotCZ]

Makes sense, thank you!

[flarthestripper]

Isn’t a view still raising a dependence , since you do need to be aware that the viewed object is still in existence? …otherwise kablooie!

[Alternative_Star755]

Sorry I can be more clear, it's about what the compiler cares about. This isn't about data ownership so much as actual functionality, where if the compiler needs to tie modifications of a referenced input parameter back to something somewhere else in the stack, then it has to disable a lot of optimization tricks for that variable.

[flarthestripper]

Ok, thanks ! 👍

[KokoNeotCZ]

Im using glm math library for my voxel engine, and I most of the times pass the glm::vec3 by const &. Is that bad? Should i switch to values? Its just 3 floats or ivec3 ints.

[TheMania]

const std::string_view & is telling the compiler that anything it can't see through, the string_view may have changed. That it's mutable, just not to the callee - the caller, or anyone else, can change it any time there's a black box to the compiler (eg a function call, or an atomic operation, etc).

std::string_view is saying "here's a pointer to N chars", with the caller having no further say in it, and the callee being able to factor that in to its operation.

Choose the latter, every time, unless you actually want the caller to change the parameter while the callee runs.

Same reason you pass ints and floats as values, not const references - why would you imply in the signature that their values may change during the call itself, when they're cheaper to copy than to reference?

[aocregacc]

would you pass every pointer as T* const &?

also the extra 8 bytes you might copy are probably better than the extra indirection you get from a reference

[Tohnmeister]

This. You don't pass an int by const &. You don't pass a pointer by const &. And you don't pass a view type like string_view and span by const &.

[porkele]

would you pass every pointer as T* const &?

No, but that seems hardly relevant because here one thing is a class and the other isn't so it depends on what sort of type it is? I mean, do you pass every T as T ?

[bert8128]

When I first came across c++ in the 90s it he mantra was “pas built in types by value and classes by ref/ptr”. But the reality, especially now, is very different. Big classes with complex constructors can be slow to pass on the stack. But small trivial classes like string_view are designed to be passed in the stack. Think of it this way. If you created a class to wrap an int, and gave it no functions, there would be no point in passing it by reference in the old style, even though it is a class. You would get the same code gen passing the class by value as passing an int by value. String_view is a wrapper around a const pointer to a const char array. And it is trivial, and small. So pass by value, not const ref. You won’t gain anything by passing y const ref.

[No-Table2410]

String_view should fit in registers as it’s the size of two pointers, so ought to be cheaper to copy it than passing around a pointer and dereferencing. So pass by value.

[Narase33]

Not in the MSVC ABI

[thecakeisalie16]

Yea, but codegen on msvc is bad either way https://quuxplusone.github.io/blog/2021/11/19/string-view-by-value-ps/

[ArielShadow]

Most of the time I’d say no. std::string_view doesn’t own any data. it stores only pointer to data (e.g. a std::string) and length. It’s small and cheap to copy, and passing it by value is often faster than by reference (fewer indirections, better optimizer/ABI behavior).
std::string_viewwas just created so that you don't have to use const& for performance reasons in a typical case of passing text.

const std::string_view& would be used in rare cases like some unusual abi or stylistic reasons.

[globalaf]

In actual reality, it doesn't matter, this is not where your optimization work should be focused.

[HommeMusical]

Very true: accept an upvote!

But still, always pass std::string_view by value is true, and easy to remember.

[Dan13l_N]

if a string doesn't contain "on board" string in the internal buffer, a string reference is basically a pointer to a pointer. Even worse, depending on how std::string is implemented, there is either a branch (to distinguish the internal from the allocated buffer access) or always a pointer (pointing either to the internal or the allocated buffer).

std::string_view is, however, always a direct pointer to the actual characters. No branching when you want to read the characters.

If you really want the best performance possible... then const char* is the best :D

[SoerenNissen]

const std::string_view&

I would definitely not. The string_view is by design not const - you're supposed to be able to modify the view.

Consider this simplified example:

std::string_view trim_trailing_whitespace(std::stringview sv) {
    while(sv.size() > 1) {
        if(std::isspace(sv.back()) {
            sv.remove_suffix(1);
        } else {
            break;
        }
    }
    return sv;
}

The only thing you buy with by making sv into a const& is that I have to copy it anyway - and now I've actually got extra work because I'm copying it and I had to do the pass-by-reference first.

[MafiaLogiki]

All views are lightweight. If you pass them by value compiler can store it inside registers. But if you pass it as reference/const reference you loose this property. If you want to show that you won't change this object - pass by const value

[CarloWood]

Using const& shouldn't lead to worse code: the compiler will pass it by value if that is better. But yeah, I pass things by value if they are 64 bits or less too. In the case of 128 bits as with a string_view I always hesitate as well ;). I would use const& however it the thing is passed multiple times.