<html><head></head><body><div class="yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><span>Am Freitag, 22. Februar 2019, 07:43:50 MEZ hat Steve Lhomme <robux4@ycbcr.xyz> Folgendes geschrieben:<br><br>> Not only gdb+qt is a bad combination (you either choose to get 20 breaks<br>> at each run or break on legit asserts) but it's not the worst part.<br>> <br>> VLC has hundreds of DLLs and loads tens of them just to play a file<br>> (that's when you have plugins cache working). For every DLL loaded gdb<br>> tries to load the symbol. In worst cases (if you happen to set more than<br>> 2 breakpoints) it can take 1s per DLL on my super fast machine (and all<br>> other machines I've used in the past years). Making debugging any line<br>> change a nightmare. Let alone the code that times out because the<br>> debugger didn't finish loading some other parts.<br>> <br>> MSVC has none of these issues, it's very fast to load and you can put<br>> keep 100 breakpoints and works just as fast.<br><br><br>I did a quick profiling of gdb when starting vlc, and found a very obvious<br>bottleneck.<br>Each time a dll is loaded/unloaded, internally a new list of all current dlls<br>is requested, and for each one, the .text section offset is read of the file.<br>And if the list is long, the list is transmitted in multiple parts, and all of<br>that is done for each part submitted.<br>So if you have a lot of loaded dlls, a lot of file-reading is happening.<br><br>I've made a simple change to read this offset only when the dll is added to the<br>internal list (and remember it).<br><br>=== ORIGINAL GDB ===<br>with plugins-cache:<br> - startup: 5s<br> - shutdown: ~1s<br>without plugins-cache:<br> - startup: 1m 50s<br> - shutdown: 1m 45s<br><br>=== NEW GDB ===<br>with plugins-cache:<br> - startup: 4s<br> - shutdown: 1s<br>without plugins-cache:<br> - startup: 10s<br> - shutdown: 3s<br><br>You can try it out here: https://github.com/ssbssa/gdb/releases<br><br><br>I also tried to see why breakpoints slow gdb down so much.<br>It's a similar problem, each time a dll is loaded/unloaded, all breakpoints<br>are reset, which means for each breakpoint all loaded dlls are checked for<br>any symbol the breakpoint could match.<br><br>That's obviously also very slow, but from what I can tell, this same problem<br>should exist on Linux as well.<br></span><div><span>So sadly I don't have a solution for this.</span></div><div><span></span><br></div><div><br></div><div><br></div><div>Regards</div><div>Hannes Domani<br></div></div></body></html>