<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/62079>62079</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            llvm-cov export spends most of its time in skipOtherFiles
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          jonhoo
      </td>
    </tr>
</table>

<pre>
    As part of digging into [a performance issue](https://github.com/mozilla/grcov/issues/1013) in a tool built on top of `llvm-cov` (specifically, it calls `llvm-cov export`), I realized that `llvm-cov export` was taking upwards of 4s to run on a modestly-sized input. That is, it takes 4s to complete this invocation:
```
llvm-cov export some-binary --instr-profile some.profdata --format lcov > /dev/null
```
where `some-binary` is a Rust binary of about 370M and `some.profdata` is 4M. And, during this time, `llvm-cov` appears to be saturating a single core on my multi-core host.

I built `llvm-cov` from the source in `main` and ran it through `perf` and Valgrind, and an interesting picture emerged ([Firefox profiler visualization](https://share.firefox.dev/3KPNmkU)). `llvm-cov` appears to be spending a majority of its time in 
https://github.com/llvm-mirror/llvm/blob/2c4ca6832fa6b306ee6a7010bfb80a3f2596f824/lib/ProfileData/Coverage/CoverageMapping.cpp#L189-L195

The calls to that function appear to stem from this call in `renderFile`:
https://github.com/llvm/llvm-project/blob/cae2a36d480d7795c763f755d41deca0ffe02465/llvm/tools/llvm-cov/CoverageExporterLcov.cpp#L179-L181

Which is ultimately called from [`CoverageExporterLcov::renderRoot`](https://github.com/llvm/llvm-project/blob/cae2a36d480d7795c763f755d41deca0ffe02465/llvm/tools/llvm-cov/CoverageExporterLcov.cpp#L210) via `renderFiles`.

Valgrind appears to struggle to follow the full call-graph, but from what I can see, it appears that `skipOtherFiles` is called upwards of 650k times. It also appears to be the case that `renderRoot` is itself called 300k times (possibly by itself — the call graph is unclear). In other words, it's not clear that `skipOtherFiles` _itself_ is the problem (although it _is_ doing a linear search as part of an iterator if I read it correctly?); the problem may be in the number of times it gets called. Perhaps some caching of its results are warranted?

My lack of LLVM knowledge is preventing me from digging much further into this, but I'd be happy to run additional commands/instrument `llvm-cov` in whatever ways may be helpful to surface more information to track down the underlying issue.

In case it matters, I'm running on an aarch64 host.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzEVktv4zgS_jX0pWBDpmzJOviQfhgINtltDGZnj42SWJLYoUiBpOzx_PpFUXJeE3RjTwsEgSWxivV99dUDQ9CdJTqK_Sex_7LCKfbOH3842zu3qp26Hu8CjOgjuBaU7jptO9A2OhD7Twgj-db5AW1DoEOYSOy_CHnoYxyDyO-EPAl56nTsp3rTuEHI0-D-0sYgv_aNOwt5SnZByNM22-ZCVqAtIETnDNSTNhGchehGDkAUmTHnYc2GRQZCHsJIjW51g8ZchfwMOgL_Dq-PAv05Oh9FkQlZ8aF78IRG_0UKYo_x47NwwQARnxjwNF7Qq8Ah7AJEB36yHBbC4BSFaK7rkNxpO05xA7-zVx2WgCI-UVgMGzeMhiJB7HUAbc-uwaidZbKyLyK74yjnv_T4Li4IbqB1rS36K6zX2obo16N3rTaUvm34QWFEWK9TZiIYNhf5VxDypIgZt5MxH9526ckT0_HqGqZCB0D4bQoRlqtdC1i7KUJeZo-AVt2Mnu9fzHaPG7iziplQk2cuE_CoB-J37xKK40joE1E1QcA4eYxshBC07QxB4zwx88MVhslEvU4vehfiZkGU_t8v0nnnv_VugNgzVZNnyVo-MaC26XarwKNNKeu9m7qev7LEb1__QNN5PcPhZz5sI3kKKcpRN3HyBDSQ70ixPsX-00l7at2fsKTJw1mHieU3J_6Dggk9etq0s91mzln-j2__HJ7-nRRcbX5B3EhWzbQN-MN5HVPGdJyJT7ATTT-p0-R90N47vzwJeaqNq4U8yWbXYHHIZYtFnWcFUYFlts3qtj5kmLdyXxXtQe7YULPBtxn6F9aFPH12Z_LY0aufjziO2nabZhyFzB-2h2r9sK32r1P6e09LaUc3l2072YYpXNDz-xBpuGVZh3R-SbInq8iftCFW-63afkHAjYfRux_UxBcGGiSJeaF2h0yVZbVvyiJvy_1e7baKGszaljK5K_YvfrifhZu_ufHdwH9NpU3-oXHnZwZKZuCwfc3Af3rd9FxULPwBI5lrQkhqhsw9vMg-8soI87uZgt-cS63wV436_4tfbrlZw1nj2-QFUWRvKv1Wkq9LIEQ_ddwtooPWGeMuqejbyZhE2LrzOPZcxPUUZ-4uLKh7aNBCIFoa97PLZUiEJz3-K_YvkcCiMVKvR0Sxz55SoYUN3EdAE9y7Ao1Jy4GePb9JDXvVMZBpb87z7OaRe8roQtC1uUJ9Xc6Jz1LcZeKrFIdMVLv5MS4FAwlt0o1tDKFPDeTegmMocHFeLZNKyDKAdRHSsZ_A_j5f-52d8jWjd7WhgYNDE_vUOnWE7zp8B-XmTmS0ZaeB0Dc94MtWkToueYzOg27n4azSIHfeUxPNVeQn7nv5pzeXDXhlLrVNb-001OTZ38yTjtBRvKVnA9_I9ziGNCShwabnqJam6ClMJgZAT3BB79FGUnzpK509XsFg88QmDw9_PMKTdRdDquO9B0ZPZ7JpBgw0C-q2Kw1T00M7-cR1Wpy4M920dy9kqRhFj-N4vW0WqJTmxoaG94UBLSfolIb9NJD921jTNumXzpxOvIYbNT2ZsZ1MKonJt9gQDDwutZ1XA502K4iegSl3mZmcWIrmmhY9Xs3eDlY7C1dHGDBG8gkKwxg4dJtYtZxT5DwXu3k2r9QxV1Ve4YqO2-KwlcW22JWr_ljivlD7XbvD_JBXsqxwi7Kuq31dVwdZZCt9lJnMs91WZtuslOUmb5pSYZXtD1KVxaERu4wG1GbDjGyc71Yp6mMhs7JaGazJhLTeSmnpsmypUvK264-JxXrqgthlRocYXrxEHQ0d_7Z_8WgNMLgQ34_Ut2Wymrw5_s_t9XkXTtH_NwAA__9DZtu4">