Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Compile-time JSON deserialization in C++

medium.com

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Compile-time JSON deserialization in C++

#81

Post by ArtixFox »

lispm wrote: post #79
ArtixFox wrote: post #73

Earlier quoted context omitted.

Im sorry i similar things on my sbcl, and i cannot see the output you are seeing. CL-USER> (defun fx-add (x y) (declare (optimize (speed 3) (safety 0) (debug 0)) (type fixnum x y)) (+ x y)) [OUT]: FX-ADD CL-USER> (disassemble #'fx-add) ; disassembly for FX-ADD ; Size: 27 bytes. Origin: #x55498736 ; FX- ADD ; 36: 48D1FA SAR RDX, 1 ; 39: 48D1FF SAR RDI, 1 ; 3C: 4801FA ADD RDX, RDI ; 3F: 48D1E2 SHL RDX, 1 ; 42: 710A JNO…

> SBCL is mediocre at best at optimizations but most people do say that. I would think that it takes a bit more knowledge to judge that. You'll need to understand a bit more how to declare types to achieve better results.

I mean medicore compared to c++/c Not Java or c#. My bad.

Re: Compile-time JSON deserialization in C++

#82

Post by matheusmoreira »

OskarS wrote: post #41
chipdart wrote: post #33

Earlier quoted context omitted.

> I am afraid of the compile-time cost. Even though compilation time is the bane of C++, I think this concern regarding this specific usage is grossly overblown. I'm going to tell you why. With incremental builds you only rebuild whatever has changed in your project. Embedding JSON documents in a C++ app is the kind of thing that is rarely touched, specially if all your requirements are met by serializing docs at com…

There is another scenario where this is an issue: if this code ends up in a header which is included in a lot of places. You might say "that's dumb, don't do that", but there is a real tendency in C++ for things to migrate into headers (because they're templates, because you want them to be aggressively inlined, for convenience, whatever), and then headers get included into other headers, then without knowing it you…

> CommonUtils.hpp

That's the root cause of the slow build. That file is likely to be depended on by way too many other files, triggering massive rebuilds when unrelated code is modified. The headers should be as granular as possible. Breaking up the generic utils file into many specific files will help contain the damage whenever any given file is changed.

I wish it was possible to track source code dependencies at the function level.

Re: Compile-time JSON deserialization in C++

#83

Post by erik_seaberg »

matheusmoreira wrote: post #82
OskarS wrote: post #41

Earlier quoted context omitted.

There is another scenario where this is an issue: if this code ends up in a header which is included in a lot of places. You might say "that's dumb, don't do that", but there is a real tendency in C++ for things to migrate into headers (because they're templates, because you want them to be aggressively inlined, for convenience, whatever), and then headers get included into other headers, then without knowing it you…

> CommonUtils.hpp That's the root cause of the slow build. That file is likely to be depended on by way too many other files, triggering massive rebuilds when unrelated code is modified. The headers should be as granular as possible. Breaking up the generic utils file into many specific files will help contain the damage whenever any given file is changed. I wish it was possible to track source code dependencies at t…

GCC, LLVM, and MSVC++ all support precompiled headers. How often is a unique and minimal set of #includes worth the extra cost?

Re: Compile-time JSON deserialization in C++

#84

Post by matheusmoreira »

_nalply wrote: post #19
threatripper wrote: post #11

Earlier quoted context omitted.

Is this real? It can't be real. Nobody can be this stupid. But then again it takes a special kind of person who doesn't understand satire to actually do something like that. Somebody, where they would say "we trained him wrong on purpose as a kind of a joke".

It's the inner platform effect. When I was young I fell into the same trap. I invented a flexible database schema where I put each field into a database row with some metadata describing the field. But that's nonsense. Just use what the database provides. There's a Wikipedia page about it: https://en.wikipedia.org/wiki/Inner-platform_effect A variant of it is: Any sufficiently complicated program contains a slow and…

Any sufficiently advanced tagging system turns into dynamic typing for databases.

Re: Compile-time JSON deserialization in C++

#85

Post by matheusmoreira »

erik_seaberg wrote: post #83
matheusmoreira wrote: post #82

Earlier quoted context omitted.

> CommonUtils.hpp That's the root cause of the slow build. That file is likely to be depended on by way too many other files, triggering massive rebuilds when unrelated code is modified. The headers should be as granular as possible. Breaking up the generic utils file into many specific files will help contain the damage whenever any given file is changed. I wish it was possible to track source code dependencies at t…

GCC, LLVM, and MSVC++ all support precompiled headers. How often is a unique and minimal set of #includes worth the extra cost?

That helps reduce the cost of parsing the headers but doesn't eliminate the issue. Changing a header triggers a rebuild of everything that includes it. If the header is ubiquitous, nearly everything gets rebuilt.

We want to reduce the set of rebuilt files to a minimum. That means separate headers so that files that use A don't need to be recompiled because B changed and A and B are defined in the same header.

Taking this logic to the extreme would lead to one file per type or function. I've read a lot of code that's structured this way and it works well. Editing lots of small files is a little annoying though. In the end it's a tradeoff.

Re: Compile-time JSON deserialization in C++

#86

Post by OskarS »

matheusmoreira wrote: post #82
OskarS wrote: post #41

Earlier quoted context omitted.

There is another scenario where this is an issue: if this code ends up in a header which is included in a lot of places. You might say "that's dumb, don't do that", but there is a real tendency in C++ for things to migrate into headers (because they're templates, because you want them to be aggressively inlined, for convenience, whatever), and then headers get included into other headers, then without knowing it you…

> CommonUtils.hpp That's the root cause of the slow build. That file is likely to be depended on by way too many other files, triggering massive rebuilds when unrelated code is modified. The headers should be as granular as possible. Breaking up the generic utils file into many specific files will help contain the damage whenever any given file is changed. I wish it was possible to track source code dependencies at t…

It's not just that. If ALL that was in the header was the function prototype, that adds basically nothing to the compile time. The problem is when you have significant codegen and parsing in headers, like you do with templates and class definitions and stuff like that.

Like, most C projects import enormous headers with gazillions of function prototypes without having a particularly measurable impact on compile times (compile times in C is quite good, in fact!)

Re: Compile-time JSON deserialization in C++

#87

Post by dctwin »

abbeyj wrote: post #14

Could you use something like `template constexpr inline Key key;`? Then you could write `key ` instead of `Key {}`, saving you from needing the `{}` each time.

Oh I think I finally groked what you suggested! Something like

template static constexpr Key key

in the class namespace - I think this this would work, but if I understand this correctly, You would need to do like

User user {...}; user[User::key]

Which actually is not so bad...

Re: Compile-time JSON deserialization in C++

#88

Post by matheusmoreira »

OskarS wrote: post #86
matheusmoreira wrote: post #82

Earlier quoted context omitted.

> CommonUtils.hpp That's the root cause of the slow build. That file is likely to be depended on by way too many other files, triggering massive rebuilds when unrelated code is modified. The headers should be as granular as possible. Breaking up the generic utils file into many specific files will help contain the damage whenever any given file is changed. I wish it was possible to track source code dependencies at t…

It's not just that. If ALL that was in the header was the function prototype, that adds basically nothing to the compile time. The problem is when you have significant codegen and parsing in headers, like you do with templates and class definitions and stuff like that. Like, most C projects import enormous headers with gazillions of function prototypes without having a particularly measurable impact on compile times…

Right. For a second I forgot this was a C++ discussion.

Breaking up the headers into granular files should still help reduce the amount of instatiation that's going on at compile time provided there isn't much overlap in the headers included by the source files.

Re: Compile-time JSON deserialization in C++

#89

Post by fsloth »

qsdf38100 wrote: post #63
fsloth wrote: post #57

What a beautiful example of abuse of C++ templates. I love it. But please don’t do this in production. What ever you need to do, use C++ templates as the last resort because you’ve figured out all other approaches suck even more. Maintaining template heavy code is absolutely horrible and wasteful (and if it’s C++ production code we measure it’s lifetime in decades). And no, there is no way ”to do it correctly so it d…

This reminds me of some coworkers I had that moaned anytime they saw 'template' in some code. They were convinced that templates were just bad, and that they should stay in the STL. Some of these people would then proceed to use void* and enums to perform the same computations (the C++ haters kind), or use virtual functions all over the place (the java-background kind). Not only was the result much more fragile (comp…

No, don’t abuse the language.

Wrap everything in types and all is fine.

Verbose C++ is the only good kind of C++. Why?

C++ code needs to be debuggable and modifiable so when a profiler shows hotspots, you know where they are coming from and react appropriately.

How do you fix a hotspot on a one line of code somewhere in the middle of a template thingsmajic?

You don’t. You need to unroll the template code to untemplated code and the fix the hotspot.

Cases where you don’t need to fix one line hotspots because the resources consumed by the code are irrelevant are fine. But if performance does not matter it likely means you should use a bette language than C++.

Using C++ and not caring about performance finetuning is the worst of both worlds - you are using a cumbersome language AND it’s not even for any practical benefit.

Post reply on HN