Binary size overhead from std::locale

[CrustyAuklet]

This might be out of scope for the library, but I thought I would start a discussion. I've been looking at this library for our larger systems but got really excited when you mentioned using it in embedded systems on cpp weekly. My main use in embedded is just to provide a JSON pointer interface over serial to c++ structured data, just get/set really. So I tried adding just the minimal to get that feature and see what happened.

// include these headers directly to avoid the thread pool since we
// don't have mutex or thread headers on the default gcc-arm-non-eabi
#include <glaze/core/common.hpp>
#include <glaze/core/meta.hpp>
#include <glaze/core/macros.hpp>
#include <glaze/json/json_ptr.hpp>

struct macro_t {
    double x = 5.0;
    int z = 55;
};
GLZ_META(macro_t, x, z);

int main() {
    backend::init();

    macro_t s{};
    auto d = glz::get<double>(s, "/x");
    volatile double d_val = d.value();  // volatile just to cheat the optimizer

    backend::start_scheduler();
}

This addition took my MCU from 30% code space to 95%. Diff output of bloat below,
and you can see it's due to locale. I could tell just from the size difference since I have been
experimenting with using std::streambuf recently and it has the same locale issue.

I haven't dug into the blaze code, but from my iostream experimentation I know any instantiation
of an iostream type will drag in std::locale and instantly bloat the binary by ~170KB.

    FILE SIZE        VM SIZE    
 --------------  --------------
   +30%  +280Ki  +864%  +114Ki    [935 Others]
   +53% +42.6Ki  [ = ]       0    [section .debug_frame]
  +1.7% +33.0Ki  [ = ]       0    [section .debug_str]
  +0.5% +19.0Ki  [ = ]       0    [section .debug_info]
  [NEW] +13.5Ki  [NEW] +11.3Ki    std::num_get<>::_M_extract_int<>()
  [NEW] +6.04Ki  [NEW] +5.12Ki    std::__cxx11::time_get<>::_M_extract_via_format()
  [NEW] +5.85Ki  [NEW] +4.98Ki    std::time_get<>::_M_extract_via_format()
  [NEW] +5.56Ki  [NEW] +5.20Ki    __strftime.isra.0
  [NEW] +5.42Ki  [NEW] +2.46Ki    std::num_get<>::do_get()
  [NEW] +4.82Ki  [NEW] +3.96Ki    std::money_get<>::_M_extract<>()
  [NEW] +4.80Ki  [NEW] +3.86Ki    std::__cxx11::money_get<>::_M_extract<>()
   +47% +3.59Ki   +47% +3.59Ki    [section .text]
  [NEW] +3.56Ki  [NEW] +2.48Ki    std::num_put<>::_M_insert_int<>()
  [NEW] +3.36Ki  [NEW] +3.17Ki    _dtoa_r
  [NEW] +3.31Ki  [NEW] +3.10Ki    _strtod_l
  +1.0% +3.10Ki  [ = ]       0    [section .debug_loclists]
  [NEW] +3.09Ki  [NEW] +2.26Ki    std::money_put<>::_M_insert<>()
  [NEW] +3.07Ki  [NEW] +2.16Ki    std::__cxx11::money_put<>::_M_insert<>()
  [NEW] +3.04Ki  [NEW] +2.86Ki    _svfwprintf_r
  [NEW] +2.95Ki  [NEW] +1.10Ki    std::num_put<>::do_put()
 -77.7% -37.6Ki  [ = ]       0    [Unmapped]
  +5.8%  +412Ki  +176%  +172Ki    TOTAL

[stephenberry]

@CrustyAuklet
Thanks for these notes, and I am concerned with supporting glaze on small embedded devices, so I appreciate feedback.
However, glaze doesn't use those std::locale functions. I'm not sure if there's a header glaze might include that introduces this like iostream might, and I'd love to figure out why those functions are being built, because they aren't getting used.

Aside, are you building in release or debug in this case?

[CrustyAuklet]

Just including a header shouldn't drag in the code, unless it's <iostream> that instantiates the standard streams. From my iostream tests std::locale is really deeply embedded in all iostream operations. It is really unfortunate, I wanted to use std::streambuf as a stream buffer abstraction but it has std::locale as a member variable and virtual functions that use it.

I will try to make some time this week to poke a around a bit more and see if i can find the culprit. My first guess would be any standard string->value or value->string functions. The C++17 functions in <charconv> don't use locale, I am already using them in this target for my serial console.

I am compiling with GCC 12.2 and using -Os -g3, full flags (excluding error stuff and project defines) is below

-std=c++20
-Os -g3
-fno-rtti -fno-exceptions
-mlong-calls -mthumb -mcpu=cortex-m0plus
-fdata-sections -ffunction-sections
-DNDEBUG
-finline-limit=10000
-fshort-wchar -fsingle-precision-constant -funsigned-bitfields
-funsigned-char -fwrapv -fno-use-cxa-atexit -fstrict-enums
-fno-threadsafe-statics

[CrustyAuklet]

I noticed this morning that the bianry bloat happens even with no added code, so it had to be a #include <iostream> somewhere. Searching through the code I found 3 instances (outside tests).

The only one causing issues with my specific includes was in util/hash_map.hpp, and it's not needed there at all so I just removed it.

❯ bloaty --domain vm -d symbols .\TestApp.elf -- .\TestApp-base.elf   
     VM SIZE    
 --------------
   +35%    +344    main
  [NEW]    +264    _on_exit_args_instance
  [NEW]    +192    __register_exitproc
  [NEW]    +156    __lesf2
  [NEW]    +140    __atexit0
  [NEW]     +88    emutls_alloc
  [NEW]     +80    __nesf2
  [NEW]     +76    __cxa_thread_atexit
  [NEW]     +48    __aeabi_f2uiz

__cxa_thread_atexit getting added was strange to me. that is due to the static thread_local auto key = ... in seek_impl. The size isn't an issue as much as I don't know what thread_local means on a bare metal system. I am asking around about that.

[stephenberry]

@CrustyAuklet
I'd love to know what thread_local means on a bare metal system as well. If we need to add a compile time option to bypass thread_local in these use cases, I'm totally up for adding that.
And, thanks for pointing our the unnecessary include, I'll remove that.

[stephenberry]

#369 has been merged to remove the <iostream> include