Hacker News Reader

Comment by darknavi | Hacker News Reader

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.

View on HN

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.

> (...) 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.

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.

> 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?

It makes no sense at all that person concerned with slow build time rewrote slow component to compile faster?

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.

” 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++.

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.

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.

Visual Studio is what matters.

VSCode is never going to be as good, you are better of with Clion then.

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.

Assuming that you're referring to 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.

Yeah but the people implementing it are prob more interested on you moving to VS, so there a slighty conflict of interest, I appreciate their work but I also a bit sceptical and think this is the main reason behind it. 6yo is a lot of time for such an important feature. They dont they to support it on all compilers/frontends in order to release it.

> Yeah but the people implementing it are prob more interested on you moving to VS (...)

Wasn't support for submodules first added to Clang and CMake?

Also, I don't think you fully grasp the scope of this change. Some projects are still stuck on C++1 to avoid having to pay for the technical debt of upgrading the compiler. This is a flag flip away.

For modules, you need to rework your whole build system and Eve rearchitect your projects.

Think about that for a second.

I don't understand why they don't just double down on these #include <__fwd/vector.h> etc. headers. They fix everything. The only downside to them is I can't use them on a header that defines a class with std::vector member variables. But if they could make a small tweak to the language so that I could, then I'd take that over the promised modules revolution any day.

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.

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.

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)

I missed that part. That is a pretty significant downside in that case.

It places a hard scaling limit on how big an open source project can become. Projects like the Linux Kernel spend enormous amounts of political capital restraining decadent programming practices, since it's the only way a codebase like that can maintain the support of its developers and grow. For example, Linux had a rule until 2018 that everything had to be able to compile with GCC 3.2 from 2003. They're much more laid back these days, since it's difficult to imagine Linux growing bigger than it already has. But I think for a newer project like llama.cpp would be well advised to follow by example what projects like Linux did in their growth phase, rather than following their leadership today. It requires an lot of discipline, toil, and restraint to be a leader in open source, because you're essentially offering the world a pot of gold, and that only works if you keep very little for yourself.

Looking at the source code for llama.cpp, it's not strictly speaking set up for success as far as build times are concerned, is it? Having 20k+ lines is a bad idea for many reasons, and this is certainly one of them.

I'm sure the authors are brilliant in many ways, but I suspect there's room for improvement in this area.

> Does the JSON-code change frequently enough to incur build cache misses and the full minute penalty?

The moment you switch branches - it changes.

If you develop for Android - it generates build for with hash name from some CMake/Gradle variables, the moment one of those changes (like AGP version) you get a new build dir and essentially have to compile from scratch.

If you're on something reasonably smart like Bazel it will be able to determine whether the module itself has been changed and requires recompilation instead of running from cache.

Nice.

We, and majority of Android projects, aren’t on Bazel, though.

This is true, and it's kind of a bummer to be honest. There's some serious time being wasted on recompilation that could be avoided with a really sharp build system.

Bazel comes with its own bag of sharp edges though so it's unfortunately not like you can just adopt it and be on your merry way.

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.

Just because they give up their time freely it makes their decisions immune to criticism?

Constructive feedback is fine. jarts comment wasn’t that.

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?

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.

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.

What difference does it even make if it’s an open source project or not? Compile times are a big deal.

I’m not talking about compile times. I’m talking about the way people should communicate respectfully.

Well maybe you should be, since focusing on the technology is what allows our disagreements to be impersonal.

Exactly. Which, unfortunately, isn’t how you framed your original comment. Instead you talked about the authors motives and indirectly called them lazy.

If you focused your comment purely on the technology rather than making ad hominem attacks to the contributor then we wouldn’t need to be having this conversation to begin with.

Believe me, his message is as respectful as it gets.

I have far, far, FAR stronger words for “people” who don’t respect other people’s time by not caring about compile times. Words that would make Linus blush.

That’s more a statement on yourself though. You don’t need to comment that way, you choose to.

So my point stands.

I don't think a supposedly bad decision has to be answered with being snarky. A pull request, or a fork focused on reducing build times are actual net gains. From that poster's original name, seems like they went on and did just that, which is great I believe.

At the very least, giving the original developer the benefit of doubt, or assuming their decision made sense under the circumstances they were in at the time, is IMO a better start than just public criticism.

I'm defending open source developers. We can't freely modify open source code if it has glacial build times. It's specifically because people are volunteering that we should aim to be as conscientious as possible when it comes to build latency. Someone who volunteers to contribute code that compiles slowly is not being respectful of the time of all the other volunteers, which is like pumping the brakes on the open source movement. So I will make my views clear that development practices need to improve.

Those people can create their own projects then. If the library/foss project doesn’t make it because of popularity then natural selection of the code worked, if people choose to accept the latency then it succeeds because it’s utility is worth more than time saved during a compile.

That's the same argument companies like Google make when they're in the exploit phase of their lifecycle. We can afford to let search results get worse, just so long as they're no so much worse people don't turn to our competitors. However they're doing it for money, so at least they have a good reason. Who can say why someone would make their software unpleasant with template metaprogramming.

> 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.

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.

Reply on news.ycombinator.com