[PATCH] D115416: [lld-macho] Prevent writing map files on the critical path

[Vy Nguyen via Phabricator via llvm-commits]

oontvoo added a comment.

In D115416#3181890 <https://reviews.llvm.org/D115416#3181890>, @int3 wrote:

>> Profiling on my end shows that writeMapFile actually takes longer than writeOutputFile and on some cases longer than finalizeLinkEditSegment.
>
> Oh interesting... well we can stick with this order then
>
>> The async policy is preferred, but the system will choose deferred if the system is running out of memory and can't spawn another thread in efforts to not hard crash.
>
> Do you have a source for this? Because that's not what cppreference says... it just says
>
>> If both the std::launch::async and std::launch::deferred flags are set in policy, it is up to the implementation whether to perform asynchronous execution or lazy evaluation.
>
> I agree the lambda isn't necessary.
>
>> If the implementation changes behind the scenes for us
>
> cppreference describes what the standard indicates implementations should do, so this shouldn't be a concern

Ok so looks like there are two options:

  - if we don't specify the policy explicitly, then we need the `.get()` call to ensure the future actually happens.
- if we do specify the policy to `async`, then no need to call `.get()`;

(What's worse is that  all of this is implementation defined, which is to say, no guaranteed it wouldn't change).

I guess there are no great options here but the current one is fine (ie., first option). Can we at least edit the comment to say it more clearly that since the policy is not specified, it maybe lazy or async therefore we need to call `.get()` to get it eval'ed?

(Same question with int3, though - where does it say the impl will pick the best policy based on thread/memory?)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115416/new/

https://reviews.llvm.org/D115416