I work on an extremely latency sensitive application. The choice of Windows predates me, and frankly, it was a massive mistake. I am never working on Windows again after this job.
Here's some feedback for low latency development in Visual Studio. Try not to take it personally, I don't hate you, I just hate every MSVC I've ever used:
- With a profiler, we typically see only a few hundred samples in our simulation runs, the rest, between 99.999% and 99.99999% of the samples are in WaitForSingleObject. PGO compiles only 0.4% of our application for speed, and our response times are about 20 usecs slower with it on.
- RE xperf (and WinDbg): Stop bundling this shit in "Toolkits". The installers/downloaders are buggy as fuck and break the main VS2012 installer; I don't want to run a bunch of random msi files on our prod server core box; and the download pages are a maze of redirects.
- __assume is so useless. How often does someone write a branch that does nothing every time? We need manual size/speed optimization.
- PogoAutoSweep crashes threaded programs if you don't suspend every other thread but it's still quasi documented. The PogoSafeMode build flag/environment appears to be ignored.
- The filename postfix that PogoAutoSweep adds breaks the VS2012 PGO menu options.
- The VS2012 PGO instrumented/optimized menu items overwrite the target exe. So when you realize somethings wrong in the environment or click something by mistake and didn't manually reshuffle the build dir, you have to rebuild everything. Name the target .instrument.exe or put it in another or something please.
- There's nothing one can do to limit the VS2012 profiler to specific threads. I was able to write hooks to target threads in VerySleepy in an afternoon, but somehow this feature escapes MS.
- The interface for instrumenting specific functions is terrible, use a plain text file or decl_spec FFS.
- If there are #defines or other ways to detect an instrumented build, they're terribly documented.
- PGO instrumentation/optimization is woefully obtuse. What did it pick for speed? Why did it pick it? What branches did it fold/unfold? How does the pgc weighting actually work? Can I artificially create my own pgc?
A perl script that compares the offsets in objdump will give me more information than most of the MSDN articles about this shit.
- Not related to our main response loop, but we can see in our logging threads that the LFH malloc appears to often call RtlAnsiStringToUnicodestring. Seriously, what the fuck?
- Speaking of which, changing the malloc implementation is still horrible even after the VS2010 msvcrt changes. In linux, you can change LD_PRELOAD and try out tcmalloc or the Intel tbb allocator in about 3 minutes. In Visual Studio, prepare to spend a few hours getting a reasonably large project to build with these.
- Why is there SemaphoreSlim in C# but not C++? Why is there no Benaphore primitive that can also be used in WaitForMultipleObjects?
- Serious issues in Microsoft Developer Connect are often ignored, closed as behaves as expected, or dismissed off hand. For example, I was tearing my hair out over this one, and the resolution is truly outrageous: http://connect.microsoft.com/VisualStudio/feedback/details/7...
I am certain that this comment on Hacker News will make a bigger impact than anything I've ever seen on Microsoft Connect.
- RE Instrumenting profilers/bounds checkers: Any project that is reasonably large and has multiple configs/3rd party libraries is bad enough to manage in vanilla Visual Studio that instrumenting it with some other 3rd party plugin becomes a serious time sink.
- There is still no valgrind/cachegrind equivalent that provides the same level of detail. The closest thing is either Intel Pin or Rational Purify/Quantify and they are expensive and poor substitutes. Microsoft is the only company that can see and modify the source of the kernel, runtime, linker, and machine code generation, so I don't know who else they expect to write this for them.
- Our statically linked application takes 20 minutes link and the link is not parallel. C++ compiles are likewise brutally slow. We resort to developing in VS2008 and compiling release stuff in VS2012. And no, I'm not going to turn on precompiled headers, MSVC builds incorrect binaries about 5% of the time as it is.
- Concerning precompiled headers, sharing a single pch file across projects or strictly controlling a single vcproj/vcxproj with the compiled unit is de facto impossible.
