Lastly, I changed the Startup Project to Host.EXE which is where OpenConsole.exe builds – this is the open source version of conhost.exe that I wanted to look at. Then I switched the Solution Platform to 圆4 since I have a 64-bit machine and figure most people do too by now.
Once in Visual Studio, I switched the Solution Configuration to Release since performance investigations should almost always be done on Release builds to see the full effects of any optimizations the toolchain will perform. I followed the Windows Terminal repo readme to ensure I had all the right dependencies set up, then opened OpenConsole.sln in Visual Studio 2019. If you’d like to follow along at home and repeat my steps, you can also clone that repo to the commit I had at the time, 551cc9a9.
I began by forking and cloning the Windows Terminal repo. As a bonus, I happened to know from some internal conversations that conhost.exe is launched over 1 billion times a day, so if I found any optimizations they might have a measurable impact on CPU cycles spent across the globe. If I could find anything cool to optimize, it would give me a chance to contribute back as it’s open source. The Windows Terminal project was a great one because it is a sizeable C++ codebase with plenty of history and legacy.
I could have chosen a toy program to look at, but it felt like I’d learn more by approaching a real codebase of significant size.
It is, however, quite complex and difficult to learn, and I’d heard that the Visual Studio Profiler had improved a lot since I last looked at it. I have been a long-time user of the Windows Performance Analyzer (WPA), which is a great tool for doing systems-level performance analysis. Around the holidays of 2020 it was a bit quieter, and I decided it might be a great time to go investigate how the Visual Studio profiling tools worked.
0 kommentar(er)
