On 12/12/23 5:09 AM, Michael Spencer via SG15 wrote:
> On Tue, Dec 12, 2023 at 1:11 AM Boris Kolpackov
> <boris_at_[hidden]> wrote:
>
> Michael Spencer via SG15 <sg15_at_[hidden]> writes:
>
> > * Delete all the temp files at the end after linking
>
> Building a hello-world example with Clang that imports libc++'s std
> module (including building the BMI for it) takes about 1.5s on my
> machine (i9-12900K). For comparison, the #include <iostream> version
> takes 0.3s. Maybe this is acceptable but it will surely be painful
> in the educational setting, where one will presumably be making a
> lot of mistakes and thus doing a lot of recompilations.
>
>
> Yep, this is about what I would expect. My extreme aversion to having
> the frontend cache things comes from years of dealing with the issues
> it causes. I'd prefer to use the module build daemon approach for
> handling caching for this situation as it gives a single process that
> can manage the cache instead of communicating over the filesystem
> between multiple Clang instances.

What prohibits Clang from moving to a single process daemon for managing
the existing cache? Microsoft's msbuild.exe does similar for other
purposes. The idea is that, when Clang is invoked, if a daemon isn't
already running for the cache directory being used, then a daemon is
started. The daemon then automatically shuts down after some timeout
period during which it is unused. This approach works well generally. It
can encounter permission related problems in some cases when the cache
is shared among multiple users.

I agree that having multiple concurrently running processes
collaboratively managing a cache invites considerable problems for
little benefit.

Tom.

>
> - Michael Spencer
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15