Printing a character literal is more complicated than printing a string literal

Question

The following code

#include <iostream>

void foo() {
    std::cout << ' ';
}

void bar() {
    std::cout << " ";
}

produces the following output in g++ 10.2 with -O3 option:

foo():
        sub     rsp, 24
        mov     edx, 1
        mov     edi, OFFSET FLAT:_ZSt4cout
        lea     rsi, [rsp+15]
        mov     BYTE PTR [rsp+15], 32
        call    std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)
        add     rsp, 24
        ret
.LC0:
        .string " "
bar():
        mov     edx, 1
        mov     esi, OFFSET FLAT:.LC0
        mov     edi, OFFSET FLAT:_ZSt4cout
        jmp     std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)
_GLOBAL__sub_I_foo():
        sub     rsp, 8
        mov     edi, OFFSET FLAT:_ZStL8__ioinit
        call    std::ios_base::Init::Init() [complete object constructor]
        mov     edx, OFFSET FLAT:__dso_handle
        mov     esi, OFFSET FLAT:_ZStL8__ioinit
        mov     edi, OFFSET FLAT:_ZNSt8ios_base4InitD1Ev
        add     rsp, 8
        jmp     __cxa_atexit

Here we can see that in both cases std::__ostream_insert function is called, but in 2 different ways: using call and using jmp. In the first case, the space symbol is written to stack mov BYTE PTR [rsp+15], 32 and then the function is called on this address. Just because this symbol is written to the stack, the space on it must be previously allocated and, later, deallocated. So that's why the call command is used in the first case, instead of lighter jmp: we have to clear the stack after the call: add rsp, 24. So, contrary to expectations, printing a symbol takes more time than printing a string literal.

Why does this happen? Why the symbol is not stored in memory? Why the optimizer haven't chosen char-specific function to call?

Answer 1

Printing a symbol takes more time than printing a string literal

You mean Printing a char takes more instructions than printing a string literal.

If you want to claim it takes more time, you have to actually time it.

And just because the first one is the subset of the second one, the only reason I see why it can be slower is the cache-misses. So it seems that it, really, would be slower, if there were no miss.

Speculating about how things might perform is a waste of time that could be spent actually profiling it. If you don't care enough to profile it, then it's not important enough to worry about in the first place.

A cache miss is certainly much more likely with a seldom-used string literal than with a local stack variable, so "if there were no miss" is a pretty big assumption.

Why does this happen? Why the symbol is not stored in memory?

You can always check the code. In ostream line 507 for version 10.2, we see

  //@{
  /**
   *  @brief  Character inserters
   *  @param  __out  An output stream.
   *  @param  __c  A character.
   *  @return  out
   *
   *  Behaves like one of the formatted arithmetic inserters described in
   *  std::basic_ostream.  After constructing a sentry object with good
   *  status, this function inserts a single character and any required
   *  padding (as determined by [22.2.2.2.2]).  @c __out.width(0) is then
   *  called.
   *
   *  If @p __c is of type @c char and the character type of the stream is not
   *  @c char, the character is widened before insertion.
  */
  template<typename _CharT, typename _Traits>
    inline basic_ostream<_CharT, _Traits>&
    operator<<(basic_ostream<_CharT, _Traits>& __out, _CharT __c)
    { return __ostream_insert(__out, &__c, 1); }

So, the reason the symbol isn't "stored in memory" (except as the literal 32 in the MOV instruction) is that the library explicitly takes its address, which forces temporary materialization.

Why the optimizer haven't chosen char-specific function to call?

The optimizer doesn't choose which function to call in the first place. It isn't involved until after the overload is selected and temporary materialization has already happened. Expecting it to identify a completely different code path that might have generated fewer instructions is asking a lot - especially when there's no solid reason to prefer that version apart from your aesthetic preferences.

The reason the library writers chose to do this, is that they can reuse the same __ostream_insert code, which you can read here. As a library implementer this makes sense because, as you can see, it's not trivial. Single chars are still formatted output, with the same sentry, stream state and padding logic as strings.

If you wanted an unformatted char output, you should be using ostream::put(char) instead anyway, whose implementation is rather simpler.