Re: Loading some symbols, when, and index-cache
Lluís Batlle i Rossell via Gdb <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <zevoy4ps2torxbkvcik6vahtx4pxkdypsd3hhne47xgtiaqbm7@a3nojsauzd5q> |
On Mon, Apr 07, 2025 at 09:05:10AM -0300, Guinevere Larsen via Gdb wrote: > $ time ./gdb gdb --batch -ex "complete list def" #Basically the same as you > did > ./gdb gdb --batch -ex "complete list def"Â 42.40s user 1.19s system 120% cpu > 36.243 total > $ time ./gdb gdb --batch --readnow -ex "complete list def" > ./gdb gdb --batch --readnow -ex "complete list def"Â 58.32s user 1.79s > system 100% cpu 1:00.08 total > > So even with the slower expansion, GDB is still faster than if we had all > symbols being read at the start, and this isn't even taking into account the > memory usage. There are two points important: The cache should allow having a big file on disk that it's just read into memory with zero work and then all symbols are ready to search. But apparently this happens only with the "minimal" set of symbols, which is far from enough for a tab completion. And 2nd, at gdb ELF file loading, thread workers are launched to read the symbols from the CUs. Again, these seem to load only the "minimal" set of symbols. In your example of 1 minute that load of CUs runs single thread. I can't even tell that the code behaves correctly. One could say that the initial load of CUs multithread should load ALL symbols, and same about caching. Or at least that could be an option. Otherwise, the things they are meant to run faster become quite limited, while the really-slow usual completions go single-thread uncached, taking for you 1 minute. Thanks, LluÃs.