5 ms·

Compile time is largely a "developer problem", but so is the usability of a library. nlohmann/json's main perk that it is selling is that it's interface is usa

Compile time is largely a "developer problem", but so is the usability of a library. nlohmann/json's main perk that it is selling is that it's interface is usable. Whether or not a developer values usability at typing time vs compile time is an interesting thing to ponder for sure.

jart 2y ago
Compile time is a collective problem and usability is an individual problem. I work with llama.cpp. The files in that codebase that were made using nlohmann json take about a minute to compile using g++ -O3 -g, all because one guy who originally wrote it wanted to type fewer keystrokes on his keyboard by using a more magical library, and the rest of us have to suffer for it every time we experiment with a 1 line of code change to those files.
- chipdart 2y ago
  > (...) and the rest of us have to suffer for it every time we experiment with a 1 line of code change to those files. If you feel this is an issue then why don't you move it to an independent submodule that can be compiled independently? That means you can build it in parallel along with the whole project, and in the end you just link the resulting binaries.
  - jart 2y ago
    I just wrote a new server instead. There's nothing I won't do, no lengths I'm not willing to go, when it comes to cutting back on build latency.
    - chipdart 2y ago
      > I just wrote a new server instead. I'm sorry, this makes no sense at all. Why would anyone write a new server just because a small component was taking a minute to build?
      - wiseowise 2y ago
        It makes no sense at all that person concerned with slow build time rewrote slow component to compile faster?
    - gary_0 2y ago
      I follow the same philosophy, to the point where at this point I barely use the STL; most of that template-heavy junk has been replaced in most of my projects. For instance, most of what I typically used <iostream> for was replaced with a 150-line .h (plus a 50-line .cpp that uses explicit template insantiation and a <charconv> include). {fmt} was too heavy for me. And I'm locked into C++17 because C++20 seems to double down on the 20k-line header madness. When I was stuck with C++ codebases that forced me to take a mandatory coffee break every time I needed to run a bit of new code, it made me a little bit insane! Never again.
  - fsloth 2y ago
    ” If you feel this is an issue then why don't you move it to an independent submodule that can be compiled independently?” If it’s a header, you necessarily can’t. Header gets included every time you want to compile code that depends on a header. Compilers may offer precompilation etc but if the code you want to change has direct dependency to a large header you need to recompile all of the dependencies. This is one of the painpoints C++.
    - pjmlp 2y ago
      It is a pain point of build management regardless of the language, even with a language having proper modules one can have a cascade build, if the public interface or module ABI is impacted. C++ modules are here, unfortunely outside VC++ and clang latest, plus MSBuild or CMake/ninja, they are not an option.
      - papichulo2023 2y ago
        Are they? According to some people (github issue to support cpp modules on vscode) the standard is mess and is likely to go away. VSCode doesnt support modules atm.
        pjmlp 2y ago
        Visual Studio is what matters. VSCode is never going to be as good, you are better of with Clion then.
        fsloth 2y ago
        This! As win/mac user Visual Studio is my preferred tool, but in MacOS Clion (with vscode for few random workflow things not supported in Clion) is an adequate replacement (but Visual Studio remains king). VSCode can be used as an industrial editor if one likes to, but if it does not feel right, it’s not a skill issue.
        int_19h 2y ago
        Assuming that you're referring to https://github.com/microsoft/vscode-cpptools/issues/6302 https://github.com/microsoft/vscode-cpptools/issues/6302, I see two comments along these lines, neither of which is from actual implementers. That isn't evidence either that the standard is a mess, nor that it's likely to go away. The reason why this is taking such a long time is because the entire approach is a rather drastic change to how C++ compilers usually work, and C++ compilers (or even frontends, such as the stuff used by IDEs) are complicated things that aren't trivial to make major changes to.
- occz 2y ago
  While the pursuit of faster build times is definitely a worthy cause, I feel like there's something I'm not quite seeing here. Does the JSON-code change frequently enough to incur build cache misses and the full minute penalty? Is there something inherent about the structure of the library that makes it unable to have its compilation be cached? Is the code structured in such a way that editing other code requires also invalidating the cache for the JSON-related code? I guess one way would be to break out the JSON parsing code to its own module and have it produce language-specific structs to be interacted with by the rest of the program.
  - jart 2y ago
    Programming is the process of manipulating data structures, so if you're building a JSON server, then every piece of code in your server is going to be dealing with and operating on JSON data structures. It can't be neatly tucked away in a corner. Because it would be foolish to design a server that makes needless copies of all its inputs and outputs. This truth would be the same if you were using something like protobuf instead. Therefore it's important that your fundamental data structures be something that (a) you can control, and (b) doesn't make everything it touches take forever to build. Do you feel in control of someone else's 24000 line header full of template magic? If that thing is sitting between me and my data structures, then I will wipe it out of existence.
  - mort96 2y ago
    It seems like nlohmann/json is a header-only library, meaning the entire library has to be compiled once for every source file which uses it any time that source file or its includes has updated. So I guess in a JSON-heavy code base or a code base where nlohmann/json has leaked into common headers, you may end up recompiling the library a few dozen times per build where a few dozen of your C++ source files must be recompiled (e.g due to common header changes)... (But don't worry, the linker will then spend a bunch of time throwing away almost all of that work so you only get one copy of the library in your binary)
    - occz 2y ago
      I missed that part. That is a pretty significant downside in that case.
- hnlmorg 2y ago
  As a prolific contributor to open source yourself, I’d have expected you to be a little more sympathetic to other open source developers giving up their time freely. For some contributors, they’ll have a day job, a family and other personal commitments. so writing open source code is a luxury they don’t have a lot of time for. I know this because I fall exactly into that camp myself.
  - wiseowise 2y ago
    Just because they give up their time freely it makes their decisions immune to criticism?
    - hnlmorg 2y ago
      Constructive feedback is fine. jarts comment wasn’t that.
      - wiseowise 2y ago
        We will never know if jarts comment was constructive or not until we know original developers decision process. If original decision process was indeed “less keystrokes”, then how is that not a constructive criticism?
        hnlmorg 2y ago
        The developers motives doesn’t change the snarky way jart wrote their comment. And if you felt their comment was acceptable then I question how much you’ve contributed to open source yourself. Snarky comments like jarts are all too common and really demotivate people from maintaining popular projects. But don’t just take my word on it, there’s a plethora of other contributors who’ve talked about this topic as well.
        TeMPOraL 2y ago
        Where's the snark though? jart's comment reads true literally. Compile times are a big deal, and 'jart is right about individual vs. collective problems. And unlike most other critics on the Internet, 'jart actually provided a solution along with the criticism. If that kind of behavior "demotivates [some] people from maintaining popular projects", I still feel it's a net win.
chipdart 2y ago
> Compile time is largely a "developer problem", but so is the usability of a library. Compiler time is way more than a "developer problem". It's an operational problem that ends up permeating to software architecture and development practices, and ultimately affects how the whole project is delivered and deployed.
marmakoide 2y ago
Significantly faster compilation means less friction to iterate ideas, try things, which in the end lead to more polished results. A nice interface is agreable, but maybe there are diminishing returns when you pay it with large compile time. I remember pondering about that when working with the Eigen math library, which is very nice but such a resource hog when you compile a project using it.

jart 2y ago

Compile time is a collective problem and usability is an individual problem. I work with llama.cpp. The files in that codebase that were made using nlohmann json take about a minute to compile using g++ -O3 -g, all because one guy who originally wrote it wanted to type fewer keystrokes on his keyboard by using a more magical library, and the rest of us have to suffer for it every time we experiment with a 1 line of code change to those files.

chipdart 2y ago
> (...) and the rest of us have to suffer for it every time we experiment with a 1 line of code change to those files. If you feel this is an issue then why don't you move it to an independent submodule that can be compiled independently? That means you can build it in parallel along with the whole project, and in the end you just link the resulting binaries.
- jart 2y ago
  I just wrote a new server instead. There's nothing I won't do, no lengths I'm not willing to go, when it comes to cutting back on build latency.
  - chipdart 2y ago
    > I just wrote a new server instead. I'm sorry, this makes no sense at all. Why would anyone write a new server just because a small component was taking a minute to build?
    - wiseowise 2y ago
      It makes no sense at all that person concerned with slow build time rewrote slow component to compile faster?
  - gary_0 2y ago
    I follow the same philosophy, to the point where at this point I barely use the STL; most of that template-heavy junk has been replaced in most of my projects. For instance, most of what I typically used <iostream> for was replaced with a 150-line .h (plus a 50-line .cpp that uses explicit template insantiation and a <charconv> include). {fmt} was too heavy for me. And I'm locked into C++17 because C++20 seems to double down on the 20k-line header madness. When I was stuck with C++ codebases that forced me to take a mandatory coffee break every time I needed to run a bit of new code, it made me a little bit insane! Never again.
- fsloth 2y ago
  ” If you feel this is an issue then why don't you move it to an independent submodule that can be compiled independently?” If it’s a header, you necessarily can’t. Header gets included every time you want to compile code that depends on a header. Compilers may offer precompilation etc but if the code you want to change has direct dependency to a large header you need to recompile all of the dependencies. This is one of the painpoints C++.
  - pjmlp 2y ago
    It is a pain point of build management regardless of the language, even with a language having proper modules one can have a cascade build, if the public interface or module ABI is impacted. C++ modules are here, unfortunely outside VC++ and clang latest, plus MSBuild or CMake/ninja, they are not an option.
    - papichulo2023 2y ago
      Are they? According to some people (github issue to support cpp modules on vscode) the standard is mess and is likely to go away. VSCode doesnt support modules atm.
      - pjmlp 2y ago
        Visual Studio is what matters. VSCode is never going to be as good, you are better of with Clion then.
        fsloth 2y ago
        This! As win/mac user Visual Studio is my preferred tool, but in MacOS Clion (with vscode for few random workflow things not supported in Clion) is an adequate replacement (but Visual Studio remains king). VSCode can be used as an industrial editor if one likes to, but if it does not feel right, it’s not a skill issue.
      - int_19h 2y ago
        Assuming that you're referring to https://github.com/microsoft/vscode-cpptools/issues/6302 https://github.com/microsoft/vscode-cpptools/issues/6302, I see two comments along these lines, neither of which is from actual implementers. That isn't evidence either that the standard is a mess, nor that it's likely to go away. The reason why this is taking such a long time is because the entire approach is a rather drastic change to how C++ compilers usually work, and C++ compilers (or even frontends, such as the stuff used by IDEs) are complicated things that aren't trivial to make major changes to.
occz 2y ago
While the pursuit of faster build times is definitely a worthy cause, I feel like there's something I'm not quite seeing here. Does the JSON-code change frequently enough to incur build cache misses and the full minute penalty? Is there something inherent about the structure of the library that makes it unable to have its compilation be cached? Is the code structured in such a way that editing other code requires also invalidating the cache for the JSON-related code? I guess one way would be to break out the JSON parsing code to its own module and have it produce language-specific structs to be interacted with by the rest of the program.
- jart 2y ago
  Programming is the process of manipulating data structures, so if you're building a JSON server, then every piece of code in your server is going to be dealing with and operating on JSON data structures. It can't be neatly tucked away in a corner. Because it would be foolish to design a server that makes needless copies of all its inputs and outputs. This truth would be the same if you were using something like protobuf instead. Therefore it's important that your fundamental data structures be something that (a) you can control, and (b) doesn't make everything it touches take forever to build. Do you feel in control of someone else's 24000 line header full of template magic? If that thing is sitting between me and my data structures, then I will wipe it out of existence.
- mort96 2y ago
  It seems like nlohmann/json is a header-only library, meaning the entire library has to be compiled once for every source file which uses it any time that source file or its includes has updated. So I guess in a JSON-heavy code base or a code base where nlohmann/json has leaked into common headers, you may end up recompiling the library a few dozen times per build where a few dozen of your C++ source files must be recompiled (e.g due to common header changes)... (But don't worry, the linker will then spend a bunch of time throwing away almost all of that work so you only get one copy of the library in your binary)
  - occz 2y ago
    I missed that part. That is a pretty significant downside in that case.
hnlmorg 2y ago
As a prolific contributor to open source yourself, I’d have expected you to be a little more sympathetic to other open source developers giving up their time freely. For some contributors, they’ll have a day job, a family and other personal commitments. so writing open source code is a luxury they don’t have a lot of time for. I know this because I fall exactly into that camp myself.
- wiseowise 2y ago
  Just because they give up their time freely it makes their decisions immune to criticism?
  - hnlmorg 2y ago
    Constructive feedback is fine. jarts comment wasn’t that.
    - wiseowise 2y ago
      We will never know if jarts comment was constructive or not until we know original developers decision process. If original decision process was indeed “less keystrokes”, then how is that not a constructive criticism?
      - hnlmorg 2y ago
        The developers motives doesn’t change the snarky way jart wrote their comment. And if you felt their comment was acceptable then I question how much you’ve contributed to open source yourself. Snarky comments like jarts are all too common and really demotivate people from maintaining popular projects. But don’t just take my word on it, there’s a plethora of other contributors who’ve talked about this topic as well.
        TeMPOraL 2y ago
        Where's the snark though? jart's comment reads true literally. Compile times are a big deal, and 'jart is right about individual vs. collective problems. And unlike most other critics on the Internet, 'jart actually provided a solution along with the criticism. If that kind of behavior "demotivates [some] people from maintaining popular projects", I still feel it's a net win.

chipdart 2y ago

> Compile time is largely a "developer problem", but so is the usability of a library. Compiler time is way more than a "developer problem". It's an operational problem that ends up permeating to software architecture and development practices, and ultimately affects how the whole project is delivered and deployed.

marmakoide 2y ago

Significantly faster compilation means less friction to iterate ideas, try things, which in the end lead to more polished results. A nice interface is agreable, but maybe there are diminishing returns when you pay it with large compile time. I remember pondering about that when working with the Eigen math library, which is very nice but such a resource hog when you compile a project using it.