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

    <tr>
        <th>Summary</th>
        <td>
            [clang-doc] Clang-Doc is extremely slow in producing generating LLVM docs
        </td>
    </tr>

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

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

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

<pre>
    @ilovepi, @petrhosek 

Currently clang-doc is extremely slow in producing LLVM docs, it consumes a ton of memory and kills my machine every time I attempt to generate the LLVM docs. This is extremely unusual since doxygen, and other equivalent tools  such hdoc to generate documentation is able to produce LLVM docs with significantly less memory and speed. This presents a tremendous challenge if we want clang-doc to eventually replace doxygen generated docs for LLVM. 

During my investigation I found that clang-doc has similar performance for small project as equivalent tools. But for large projects the performance deviates drastically.

I was able to use llvm TimeTraceProfiler to set a profile of clang-doc when it was attempting to generate llvm documentation

here's the tracing json file: https://drive.google.com/file/d/1GSO-eRKiSv_g4yxtHTXFuz1yi7SXpeMH/view?usp=sharing


The majority of runtime appears to be dominated by the reduction phase, with Reading the Bitcode dominating alot of the time
I think this problem is due to clang-docs the way clang-doc is architected,

Currently clang-doc uses RecursiveASTVisitor to visit every Namespace/Record/Method/Function/Typedef/TypeAlias Decl in the compilation database.  Every time clang-doc visits a Decl it saves Info on the Decl itself and creates an Info about the parent Decl and insert itself into it. 

Instead of doing this I think we should just compute all child records, typdef and etc whenever clang-doc during the recursive AST visit to a namespace or record instead of attempting to do a merge after. This is the conventional approach taken by most of the other doc generators using libtooling for documentation. 
This approach has the advantage of removing the reduction step, to gather all the info needed for a Decl, which should speedup clang-doc. 

</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyUVk9zOrkR_TTDpcsUiD82Bw62CVlX9pds2dTW3lKN1DMjWyNN1BL8yKdPtQYMJIetXPB4Rup-_V73k5DZNp5oXS1eqsVmhDm1Ia5_o0TxtQ15OtoHc1pX84l14UC9rdQrVPNJTym2gekLqsmmmjwPv685RvLJnUA79M2DCRosA_1MkTpyJ2AXjmA99DGYrK1v4Ndff_8BJmiWwDaBDp5zRwwIKXgINXTUhXgC9Aa-rHMM3Qk61K31BHSgeIJkO4I3wJSo6xOkAA15ipgIUkvXFGPYtZbvEWWfOaMDtl4TmPDz1JAXLJIvpJYi0L-yPaAjL6GDYwDOuoVWqrvNZYLOHfmEyQYvWXDvSFYM1d4AgaNNLQjztrYaC2OOmG9r5Z7InBH3kZh8KqQIbm9CZtAtOke-IbA1HAmO6NMN8SkIPT5ldO4EkXqH1wq_UZsBUB1igTe-03OTo2jUncD6A3GyzVDbG9QhewOpxduMLTKw7azDCD3FOsQOhVUJzh06J0x8kk6A_D-sjuElp7LUYWzospSLhLfRDB0sJmIwETlZLeWNb1G_wRGv5GcmcO7Qwc52tIuo6bcYausoylemBCi55I1027WaY0teOrIEG1pLyLhVvMS9k_0WR0uRKvU4VJAiln7_5OBBklWzZ2hT6rmaPVdqW6mtifZA4yaExtFYh65S27JQbU2lttO_fvzjgd7_Zj8O_2zmp5_pl90f2_zv6ck-fvzR049fKrU9WDpWs23mvpptuEVR7xZRpabV4sV22FC12FTq6R5AY1Ob9-fUUtv5z8NZi0ptkZkSV2o7ny2UUmpRqe1qtUJcLvTDdILzh_njcvmAuJo-1DSZoNZqb55UpVa3QHYtQYefIdp0EtZj9mWIse8JIwvJe-nVzvrSo_tTITGSybp0YN8ik4xpmaR3QlO0aQlebNLBfG-W1-hCkixFB9vRpU1Sa_2X_MqEhb2jTqbW5NI3340w6HfE_zI1jLq1iXQiU6nXP3PBzMTwTjpHtgd6_tj9btmmUHrwII9nK_s7dsQ9alH9nXSIIv0PSm2Qh232pfxKbXenngzV56dnZ5FhQ9qJuwpeHbreumFcDSbcI9MY4C9Xw7yCKwDEXIYACRgPxPDm6wBhCHf-wuTq4k46UplB9MMy3IechlFFKX7YICutZ4rpstf6FMCme5t585wIjUhkwqCjZbjocyTgNmRn4DNzKoXlRCB2olvrDMTCUzlA0qk3NCCkNIyw8HpTqxksbeimsxzw_LE7q5ACIPiLCBDiObqUccF4bwZGdnQkloV1ong9ZAYZvHiwDR6ddHcMqFtI-EVemroL_N2Zw2EjGM_-EiJDZknj7F48Uh7FIO8c50JlyfqdQaxYgqI5oE_YFG-L1IXDtfrLLHGivpAXoMECQriVNVak9USGTEk8dEgZu9bq9qJLOapyf2X5gmlk1jOzmq1wROvp43Sllk8r9TRq1_VqujD09PS4wPnqcUFzwqnCVY17vdJUL0d2rSZqPlmquVJzNXkaz2ZqX-NEmdlygTinaj6hDq0bi0GNQ2xGljnTerVcPE5GDvfkuFxqlPJ0hPKxUkruOHFdTG2fG67mE2c58TVKssmV29B3MdViA6_ln82fX2fO0t3dbEY5uvX_7bQFsTjtUNFhrf4TAAD__zQiXQc">