![]() It doesn’t make use of line-number information. My tests show that WPA uses a mapping between addresses and functions, and nothing else. Tracking source file numbers for inlined functions is something that only happens if you enable enhanced debugging information (previously enabled with /d2Zi , now with /Zo, discussed in more detail here), so the initial evidence suggested that it was Chrome’s use of /d2Zi that was causing its symbols to take so long to be processed.Īside: if /Zo is the problem then that makes this whole performance problem particularly annoying. The first time I analyzed this I found that almost all of the msdia120.dll samples were in Mod1::TranslateFileId, called through SymCachePdb::LoadInlineeLines. This meta-profile showed that the vast majority of the wpa.exe main-thread samples – 97% of them in the screenshot below – were in the main thread inside of msdia120.dll – which is different from the previous problem: symcache files in c:\symcache so that subsequent uses of the same symbols are much faster.Ģ5 minutes is plenty enough time to investigate so I recorded another profile during this time – profiling the profile viewer. The symbols for these two DLLs were taking a total of about 25 minutes to be loaded which was making using the profiler quite cumbersome. ![]() ![]() I soon noticed that Windows Performance Analyzer (WPA) was taking a very long time to load the symbols for chrome.dll and chrome_child.dll. (you can find the Chrome symbol server at, changed from http for greater security) I profiled the public build and used the public symbol server to automatically download full symbols. It wasn’t long before I fired up xperf (aka Windows Performance Toolkit or WPT) to see what Chrome’s performance looked like. I recently moved to Google where I’m working on Chrome for Windows. Today’s blog post documents a new problem with slow WPT symbol loading.Īnd, it appears that I’m not the only person hitting new WPT/WPA symbol loading slowdowns ( details here): I’ve previously documented slowdowns and unreliabilities with WPT symbol loading in Xperf Symbol Loading Pitfalls. The good news is that once again I was able to learn enough about the problem to come up with a very effective workaround (now available in UIforETW) in the Traces list context menu, as Strip chrome symbols, easily extendable for other problematic PDBs. This guidance applies even when the slow program is a profiler.Īnd so it is that I ended up using Windows Performance Toolkit to profile Windows Performance Toolkit. When I run into a problematically slow program I immediately reach for a profiler so that I can understand the problem and either fix it or work around it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |