To those of you who have conversely taken up my time with my unfamiliar posts, I'm sorry & thanks.
**The ccache 's cache is not shared by different projects**, sorry for posting without checking carefully. After some trial and error(ccache -o debug=true), I think the ccache manual needs to turn off the inclusion of the current directory in the hash in hash_dir(ccache -o hash_dir=false). It also seems to be "-I/cwd/path/to/headers" in the c compiler options so that nim can import c source files and header files, and I assume it is also necessary to avoid including this in the hash that is keyed to the ccache cache.(I don't know/find how to do that.) Nevertheless, it will be faster when nimcache is cleared, for example. Sorry for being so defensive... _bung_ , _juancarlospaco_ , _auxym_ , _rockcavera_ , _jasonfi_ , _thindil_ Thank you for the detailed tracing instructions. If the environment has enough RAM as you say, frequently loaded files, etc. will be loaded into the OS cache and reused. As you pointed out, it is thought that frequently read source files, etc. will be cached in tmpfs, as well as object files that are not updated. However, I did not know how to get detailed statistics (how many hits or cache misses) from tmpfs. Once again, we have summarized the results. * A second full build(No nimcache) of the project with large many files will save time and energy. * On the contrary, it is likely to be slightly slower for small projects, but it saves CPU energy because the c-compiler is not invoked, (This is the case when nimcache is removed.) probably... * **As of 2022/12, ccache 's caches will probably not be shared between different projects.** * Environments with only HDDs instead of SSDs, for example, are considered to be quite slow. It is expected to be conversely faster in environments with smaller RAM capacity. * Since there is some overlap between the OS cache, Nim cache, and ccache functions, it might be a good idea to find out which functions are contributing to the speed improvement and by how much.(When I get some time.) I really wish I could actually measure it in a tangible way like the Nim hackers do, instead of just predicting it, but I'm frustrated that I can't present it. Nim compiles so fast as it is that few people question what it is, but I think one of Nim's elegant features that does not appear in its characteristics or syntax is that it also runs efficiently with little power! Please forgive me if I have strayed quite far from the topic of Nim.
