3 ms·
> what do you know, there’s one billion stack frames from the nlohmann JSON parser, I guess it all gets inlined in the release build; My guess would be that it
by lelanthran 2y ago
> what do you know, there’s one billion stack frames from the nlohmann JSON parser, I guess it all gets inlined in the release build;
My guess would be that it's because tail-call optimisation only happens in -O2 and above.
Parsing recursively is frequently the cleanest way to implement a parser of tree-structured input, after all.
If you're doing anything recursively, it makes sense to slightly restructure the recursive call to be the last call in the scope, so that TCO can be applied.
- mst 2y agoIt looks to me like you can use -foptimize-sibling-calls to get it to happen on gcc below -O2. There's also https://github.com/pietro/gcc-musttail-plugin https://github.com/pietro/gcc-musttail-plugin to ensure it does happen (and clang has musttail support built in these days).
- mst 2y ago\o/ looks like that won't be needed much longer: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324#c27 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324#c27
- gpderetta 2y agoNot really; knowing the library, I suspect is just many, many layers of trivial templated functions that normally just get optimized away to nothing, but at -O0 bloat the code. -Og can sometimes help in these cases.