Is the usage of RUNTIME_COMPILER_SOURCEDEPENDENCY_FILE meant as demonstration only?
Closed this issue · 11 comments
It seems, the dependencies declared on the imgui file significantly slow down compilation (from 1 to 17 seconds on my machine).
I feel like they're unnecessary and meant to show how the system works, is it the case?
It might be a good idea to add a comment or a mention somewhere in that case. I nearly wrote the project off as unusable because the compilation really felt super slow.
Could you let me know what your compiler/platform is?
I am wondering if this is related to this issue, however MSVC has resolved this.
RUNTIME_COMPILER_SOURCEDEPENDENCY_FILE is required for RCC++ to link in the imgui files at runtime.
FYI for more information on the RUNTIME_COMPILER_SOURCEDEPENDENCY_FILE macro, see the wiki: https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus/wiki/Runtime-source-dependencies
Could you let me know what your compiler/platform is?
I am wondering if this is related to this issue, however MSVC has resolved this.
It's a bit late at my place so I'll read the link tomorrow but in the mean time here is my setup:
- g++ version: 14.1.1 20240507 (Red Hat 14.1.1-1)
- cmake version: 3.29.3
- ninja version: 1.11.1
I read the wiki, but was confused because I don't understand why you'd want to recompile the imgui files when changing the RCCppMainLoop.cpp file.
After reading the link, I tried using the g++ -ftime-report flag to see what was taking time in optimized builds.
All the imgui files seem to spend a lot of time (around 4 to 5 seconds per file) in the "callgraph functions expansion" step, which includes inlining. As far as I can tell, this is the reason optimised build takes around 17 seconds to compile.
In contrast, unoptimized builds take only 5 seconds. This is still more than I expect (compiling directly is around 1 second) and I think what happens is that the compiler doesn't do any multi-threading, g++ treats the input files sequentially before invoking the linker.
So for example, on my machine each file takes around a second to compile, and we have about 4 files compiling.
This means that if we could do them in parallel, we'd have around a x4 speedup for the compilation (linking would be unchanged though).
I realize this is going of-track for the main issue but I felt like this info could be useful.
I read the wiki, but was confused because I don't understand why you'd want to recompile the imgui files when changing the RCCppMainLoop.cpp file.
The RCCppMainLoop.cpp includes functions in imgui.h which require linking to. RCC++ needs information about what to link to, along with information about how to produce the files needed for linking if they do not already exist.
Whilst these have already been compiled to generate the executable, there isn't an easy and robust way in RCC++ to link to these, so instead we compile them and link to them as part of runtime compilation of this file. This is only done once, as subsequent compiles can use the produced object files.
As mentioned in the comments an alternative (and indeed usually better) way is to compile the ImGui files as a library and link to that
After reading the link, I tried using the g++ -ftime-report flag to see what was taking time in optimized builds.
I'm guessing you're referring to compilation of the entire project, rather than runtime compilation of RCCppMainLoop.cpp and its dependencies. This isn't something I can resolve.
The original issue reported of the dependencies declared on the imgui file significantly slow down compilation could be due to g++ trying to optimize a recursive template and getting stuck. This could potentially be fixed by the following change to the file RuntimeTracking.h:
Change lines 20-28 to:
// the templates used for tracking need not be optimized
// so we create macros to handle this
#if defined _WIN32 && !defined __clang__
#define RCCPP_OPTMIZE_OFF __pragma( optimize( "", off ) )
#define RCCPP_OPTMIZE_ON __pragma( optimize( "", on ) )
#else
#define RCCPP_OPTMIZE_OFF _Pragma ("GCC optimize O0")
#define RCCPP_OPTMIZE_ON _Pragma ("GCC reset_options")
#endif
I've not tested this yet, and _Pragma requires C11 or C++11. The proper solution would need push/pop as reset might clear someones own pragma options but for testing this should do.
I'm guessing you're referring to compilation of the entire project, rather than runtime compilation of RCCppMainLoop.cpp and its dependencies. This isn't something I can resolve.
Sorry I was unclear, I tested the compilation lines that were dumped by the application during runtime, to understand why it was spending 17 seconds recompiling when changing the code. The dependency on imgui is what causes the slowdown, and this seems to be linked to the fact that g++ does a lot of inlining specifically when compiling these imgui files.
A couple of things don't seem to be behaving like described though:
Whilst these have already been compiled to generate the executable, there isn't an easy and robust way in RCC++ to link to these, so instead we compile them and link to them as part of runtime compilation of this file.
I cleaned the files just to make sure, and it seems that removing the dependency works fine on my end (modifications are visible, the recompilation is fast, and i see no crash). I'm guessing maybe there's a scenario where using an imgui symbol which wasn't used before could cause a problem? I tried to create such a scenario, but so far everything seems to work.
In any case this would by minor if they weren't rebuild each time, which seems to be unexpected;
This is only done once, as subsequent compiles can use the produced object files.
They seem to be recompiled every time on my side.
I can see the code doing the detection, I'll try to investigate what is going on.
Seems the build objects are named a-XXX.o on disk, and searched as XXX.o. No idea why yet.
I opened a PR to fix this: RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus#135
I cleaned the files just to make sure, and it seems that removing the dependency works fine on my end (modifications are visible, the recompilation is fast, and i see no crash).
This isn't the case on all compilers/platforms. I'll have to investigate this a bit further at some point but do not currently have time.
I opened a PR to fix this: RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus#135
Thanks for that - I'll look into it as soon as I can.
Thanks for the explanations. I think the question is answered for me.
Cheers!