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

    <tr>
        <th>Summary</th>
        <td>
            llvm-symbolizer uses significantly more memory with zlib compressed DWARF
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            performance,
            debuginfo,
            tools:llvm-symbolizer
      </td>
    </tr>

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

    <tr>
      <th>Reporter</th>
      <td>
          sfc-gh-sgiesecke
      </td>
    </tr>
</table>

<pre>
    I built a large binary (which among others links against several LLVM libraries, I randomly picked one LLVM symbol for the test) with and without `-Wl,--compress-debug-sections=zlib` (using `lld` from `llvm-16.0.0`):
```
$ /usr/bin/time llvm-symbolizer -e binary.compressed-dwarf 0x$(nm binary.compressed-dwarf | grep _ZN4llvm3orc8JITDylib5clearEv$ | cut -c 1-16)
llvm::orc::JITDylib::clear()
.../llvm/src/lib/ExecutionEngine/Orc/Core.cpp:618:25

8.55user 0.63system 0:09.20elapsed 99%CPU (0avgtext+0avgdata 3940772maxresident)k
0inputs+0outputs (0major+767100minor)pagefaults 0swaps
$ /usr/bin/time llvm-symbolizer -e binary.uncompressed-dwarf 0x$(nm binary.uncompressed-dwarf | grep _ZN4llvm3orc8JITDylib5clearEv$ | cut -c 1-16)
llvm::orc::JITDylib::clear()
.../llvm/src/lib/ExecutionEngine/Orc/Core.cpp:618:25

0.63user 0.22system 0:01.14elapsed 74%CPU (0avgtext+0avgdata 450928maxresident)k
2129840inputs+0outputs (417major+89119minor)pagefaults 0swaps
```

WIth`--compress-debug-sections`, `llvm-symbolizer` 
1. takes significantly longer
2. uses significantly more memory (3940772maxresident vs. 450928maxresident)

1. might be expected/unavoidable due to the decompression overhead, but 2. seems unexpected/avoidable in this extent.

A similar behaviour exists with `llvm-gsymutil --convert`, which isn't surprising as this probably originates in the DebugInfoDWARF library used by both.

Just for completeness: `llvm-symbolizer` shows a number of warnings like
```
warning: address range table at offset 0x9066e0 has a premature terminator entry at offset 0x906970
```
in both cases. I guess that's not relevant here though.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJzcVluP2zYT_TX0y8ACRd2sBz843hjYIN8FRdsAfSkoaSQxS5ECh_Ta-fUFpXV2u9k0RR8LGAIpc27nDM9IEqnBIO5Z8Y4VdxsZ_Gjdnvp2O4xbGhQStg-4aWx33d9DE5T2IEFLNyA0ykh3BSZ2j6NqR5CTNQNYP6Ij0Mo8EMhBKkMeCM_opIaPH3_9D2jVOOkUEhNHuAcnTWcnfYVZtQ_YgTW4nqPr1FgNvXXgRwSP5Jmo4VH5EaTploUNHljJt580E8fttrXT7JBo22EThi1h65U1xLK7L1o1rOQx20DKDNFK6y6-6p2d1u152qZlwhPOSs5EzbID43eMH-J2_a1bkQMTp0COiVOjDBMnryaExcGatfqCDrY3jJJbXthtu0fpeuAXJnImdmb67hFWHWFwOMPvv_03j64z69rdh_uf765aNUWrUbr35yWX6ght8LBtId2mZcx8yTMaxRqyg3XturiZr7vFBxO7rxZJkjBxWuzEiVwbN6ph4vT-gm2IWL43gzLIxOl_y79H6zBp55llhzLdsewgiieMlucuKYpA6IAnZUZX8jgBZ9mB14ngqOVM2EFdM1Ec__9L5IbL8-Dx4pl4F5ed9BKyOudVJSZ5cUiqQxPb4GENwJWZg6d43AYfl4uXSX62jol3VVmlnE_KxF09ywF7GbQn4PQoZ_qndAbzNwh949C_gdLI5BOlQrykNE3S_EZplf81pXnBa7F7k1GRinqXv81rnlY3Znd1mtY_IvbVtV2en-79GBXju1oRr_7xqx4887-ox-IiTcDLBySI4ql61Urj9RW0NQO6pyoSCPTNick6hAknu8rmt40NZ0reBOdlBWkCkxpGDw0CXmZsPXaxf408W9XJRiN0AcHbRTY7vBWqrAF7Rjei7GKJTfAgEiDEiSCYF66eHSkDflQEePFofPIyjQOQmpSWDhoc5VnZ4AAvijytEn1DcKDrFLzSECE3Z3T-CeJ1aigyTFQeKLjZqUWaJa1BZ2cb2egrWKcGZaRHWhNCuIuc3Zve3n06_HR6GinXiHkHzRUa68c_JfshkF8mSQRDo0eDRCw7fIdnGu0jgQQTpgYd2B4epTPKDHGwPeCb7fV0IjqVXRcBj6NtQPALktKD7XtCD_xS87JEDqOMMWaHk_TBxQnnplimdYDGu-trm7rib0ZWZikYWklICdzDEGJ0P0rPREVgrAeHGs_SeBgxRhptGMZk0-2zrs5qucF9Wu7KsizqqtqMe9H3WVrVIi3alPeSl3lfZbls0qYr64IXG7UXXGS8TLM0T-usSqTAXuaiTvNiV2G5YznHSSqdRHQT64aNIgq4LzNR842WDWpavjqEmNH11k3StMiEYOLIhFjupDK9_frGW6sjY6_ZEiJ-uLj98r4JA7Gc69iFz5G98hr3r-X8B_dz6eH41QDPMg5Lt22C0_vR-zmmw8SJidOg_BiaOMOftXaJNzv7GVvPxGkpn5g4LQj8EQAA__9wRQr9">