vsapsai added a comment.
Sorry for the delay, I haven't finished testing more projects yet but here are
my preliminary numbers
| **File** | **Baseline (s)** | **Set Dedupe (s)** | **No external (s)**
| **Set Dedupe (percentage of baseline)** | **No external (percentage of
baseline)** |
| Project1. File1 | 1.26146575 | 0.931755875 |
0.943674125 | 73.863% | 74.808%
|
| Project1. File2 | 1.444321875 | 1.0868395 |
1.095805875 | 75.249% | 75.870%
|
| Project1. File3 | 1.2475025 | 0.94032725 |
0.942943875 | 75.377% | 75.587%
|
| Project1. File4 | 1.197715 | 0.98331625 | 0.9898685
| 82.099% | 82.646%
|
| Project1. File5 | 1.252481375 | 0.94339925 |
0.945766 | 75.322% | 75.511%
|
|
Methodology: clear a modules cache, compile a file once to pre-populate the
cache, compile file 8 times and measure elapsed time, take the time average.
Didn't include files using a precompiled header because that makes cleaning a
module cache trickier. Standard deviation of the measurements is consistent
between different approaches and doesn't go above 0.015, so I haven't included
it here. "Project1" is an app, so it should have a fairly long chain of
dependencies, though I haven't checked it in details.
So it looks like "no external" approach is slightly but consistently slower 😢
than "set dedupe" approach. I'm curious to get the results for an empty module
cache because clean builds are also important for us. And if you see anything
suspicious in the methodology, please let me know.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D109632/new/
https://reviews.llvm.org/D109632
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
