Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The compilation time is slow #1710

Closed
certik opened this issue Aug 16, 2019 · 13 comments
Closed

The compilation time is slow #1710

certik opened this issue Aug 16, 2019 · 13 comments
Labels
kind: enhancement/improvement state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated

Comments

@certik
Copy link

certik commented Aug 16, 2019

I used nlohmann::json in some AST tree to JSON conversion in a compiler, and it was very easy to get started, documentation is good, syntax is simple and it just works. However, I noticed that the compilation time of my code got really slow. So I switched to rapidjson, it took me a lot longer to get started, but when all was done, the compilation of one file got from 4.8s to 1.8s, here is the patch that achieves this speed up:

https://gitlab.com/lfortran/lfortran/commit/904cb6301e86f95e6ad86d571ea74b23cd2b0e70

and another file from 5.7s to 2.8s:

https://gitlab.com/lfortran/lfortran/commit/bfe179ec2ab72855d273db1258c858857ddb9fa2

I am posting it here as a feedback, if there is anything that you can do to speedup the compilation, that would be very helpful.

@volanin
Copy link

volanin commented Sep 3, 2019

I just want to +1 this suggestion.

Compilation with nlohmann::json is really, really slow. I use it extensively in my company's project, but since we're in the initial phase of rapid prototyping, the high compilation times are making development grind to a halt.

I found this ticket while searching for a way to improve compilation times with nlohmann::json. Even gcc precompiled headers aren't solving the problem.

@pmbittner
Copy link

pmbittner commented Sep 5, 2019

Something that could help is the forward declaration header. I used it in my project so that I only had to include json in my cpp files.
However, the json_fwd.hpp does not work ad-hoc with the singleinclude json header (you have to remove the default template arguments in json.hpp).

Another suggestion would be to introduce variability, maybe through ifdefs or multiple instead of a single header file. There are lots of cool features in nlohmann::json but as I do not need all of them, turning some things off for compilation would help, too.

@volanin
Copy link

volanin commented Sep 5, 2019

I don't think json_fwd.hpp works together with NLOHMANN_JSON_SERIALIZE_ENUM. The enums serialization must be defined in the header file, and it requires json.hpp. Or maybe I'm doing something wrong...

@ClaudiuHKS
Copy link

Constexpr slow down compilation time but should help execute code faster.

I am not REALLY sure of what I said above but I hide strings in some of my binaries using Constexpr and I see a huge difference while compiling .. like it takes more time to finish when using Constexpr.

@nlohmann
Copy link
Owner

@ClaudiuHKS Do you have some benchmarks on the effect of constexpr?

@ClaudiuHKS
Copy link

ClaudiuHKS commented Sep 20, 2019

@ClaudiuHKS Do you have some benchmarks on the effect of constexpr?

With Constexpr

#include <stdio.h>
void main (void) { constexpr char Data [8192] = { '-', }; printf ("%s\n", Data); };

Without Constexpr

#include <stdio.h>
void main (void) { char Data [8192] = { '-', }; printf ("%s\n", Data); };

You should really see the difference yourself, while compiling them, like it takes much more time to compile when Constexpr exists, but I think the code will execute faster when it runs, rather than when Constexpr is absent.

NOTE! I have tested it with Visual Studio 2019 on Windows 10, I have no idea if it's the same for other operating systems.

CPPReference states that the constexpr specifier declares that it is possible to evaluate the value of the function or variable at compile time so IMO affecting code at compile time automatically changes code at run time, at least, the way it's being executed.

@nlohmann
Copy link
Owner

I cannot reproduce this on macOS:

image

@ClaudiuHKS
Copy link

ClaudiuHKS commented Sep 25, 2019

https://pastebin.com/Wbz0rHd6

With Constexpr = Time Elapsed 00:00:02.57
Without Constexpr = Time Elapsed 00:00:00.36

@stale
Copy link

stale bot commented Oct 25, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated label Oct 25, 2019
@stale stale bot closed this as completed Nov 1, 2019
@fzyzcjy
Copy link

fzyzcjy commented Apr 15, 2021

Hi, any updates? The slowness of compilation is quite annoying :(

@mcourteaux
Copy link

Please reopen. This stale-bot is just closing valid stuff for no reason.

@nlohmann
Copy link
Owner

It's closed, because nobody was working on this, and this is a hobby project...

@certik
Copy link
Author

certik commented Mar 24, 2023

@nlohmann I see that you gave a thumbs down to my original issue report above. May I ask what I wrote that deserved this? Do you not want me to give feedback anymore? Or was the tone of my report not good (if so, how can I improve it)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: enhancement/improvement state: stale the issue has not been updated in a while and will be closed automatically soon unless it is updated
Projects
None yet
Development

No branches or pull requests

7 participants