Thanks Mathew. I guess I did not explain this well enough, I'll try to revise.

And yes, any build will obviously benefit from BMI reuse too. I just tried to give examples of the "performance critical" scenarios which duration will change significantly when they can reuse at least some BMIs vs when they need to rebuild all modules from sources. This actually includes pre-built libraries BMIs as well as "domestic" BMIs which were produced using slightly different compilation options. The more we can reuse the same BMI, the more performance improvements we'll get for module using code.

The VS editing scenario I meant is when we compile one or many sources for the first time to make various IDE editing features available. If a cpp file uses modules, we cannot start its compilation before we ensure all imported modules BMIs exist and up-to-date. This includes referenced module's BMIs too. If there is a chain of module dependencies, like C depends on B which depends on A, modules A, B and C can only be built sequentially, not in parallel. The longer the dependency chain, the longer the total build, does not matter how many cores your machine has. So if C's or B's BMI exists and can be reused it makes a big difference in total time required to get cpp compilation data for the first time. After that, you are right, the compilation for cpp changes will just use the existing BMIs and thus, hopefully, run much faster than today.

Olga

-----Original Message-----
From: Matthew Woehlke <mwoehlke.floss_at_[hidden]>
Sent: Monday, June 17, 2019 11:48 AM
To: Olga Arkhipova <olgaark_at_microsoft.com>
Cc: sg15_at_[hidden]; modules_at_lists.isocpp.org
Subject: Re: [SG15] Reuse of the built modules (BMI) paper

On 17/06/2019 13.45, Olga Arkhipova via SG15 wrote:
> I submitted the paper for BMI reuse.
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisoc
> pp.org%2Ffiles%2Fpapers%2FP1788R0.pdf&amp;data=02%7C01%7Colgaark%40mic
> rosoft.com%7C6d69e4eff1f2453f8aeb08d6f3545e93%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C1%7C636963941030718519&amp;sdata=TH%2FeO2Zu4%2FLmbIpV
> 8RZ5A%2BrmGotwdE3%2BWYSgjPHCfd8%3D&amp;reserved=0
>
> I believe I still can change it if somebody wants to comment on it.

I find your motivation (at least the "why reuse" part, but actually that's only part of the paper) unconvincing. The first point in particular; if I am modifying a.cpp, I don't need to rebuild the BMI's that a.cpp depends on, whereas I *always*¹ need to rebuild the BMI for a.cpp with or without reusable BMI's.

(¹ Pedantically, it depends on if what was changed affects the BMI or not. I'm not sure if IDE's will become "smart enough" to make this
determination.)

That's not to say there *isn't* motivation. In fact, I think you are missing the *biggest* motivation, which is, if I can reuse a library's BMI's, then the many consumers of that library don't all have to build their own copies. Maybe you are trying to say this with your second point, but it isn't clear that you are talking about BMI's of *external* libraries, as opposed to those the project itself generates.

Just some thoughts... again, not trying to knock the paper (which I think is important), just offer how you might improve how you present the "why reuse" section.

--
Matthew