{"id":3454,"date":"2017-10-31T21:24:48","date_gmt":"2017-11-01T04:24:48","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=3454"},"modified":"2017-10-31T22:21:48","modified_gmt":"2017-11-01T05:21:48","slug":"profiling-linux-c-code-with-visual-studio","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/tutorials\/profiler\/linux\/","title":{"rendered":"Profiling Linux C++ Code with Visual Studio"},"content":{"rendered":"

This tutorial shows how to profile C++ code using Visual Studio, valgrind and VisualGDB. We will show how to import the JSON for Modern C++<\/a> parser (as of 31 October 2017) into a Visual Studio project, build it under Linux, run a benchmark, quickly identify the code consuming most of the time and optimize it. We will increase the performance of the release build by over 1.5x by locating and eliminating a few bottlenecks.<\/p>\n

The techniques shown in this tutorial can work with any other C\/C++ code as well; we are using the JSON parser to simply demonstrate the functionality on a real-world project rather than on a synthetic example.<\/p>\n

Before you begin, install Visual Studio and VisualGDB 5.3 or later. Also prepare a Linux machine that will be used to build and profile the JSON benchmark.<\/p>\n

    \n
  1. Start Visual Studio and open the VisualGDB Linux Project Wizard:\"01-newproj\"<\/a><\/li>\n
  2. On the first page of the wizard select “Import a project -> Import a CMake project -> Use the advanced CMake Project Subsystem”:\"02-import\"<\/a><\/li>\n
  3. On the next page select the Linux machine you want to use for building:\"03-machine\"<\/a><\/li>\n
  4. Connect to your Linux machine over SSH and clone the https:\/\/github.com\/nlohmann\/json repository to a local directory:\"04-clone\"<\/a><\/li>\n
  5. Get back to VisualGDB Project Wizard and specify the directory where you cloned the repository:\"05-dir\"<\/a><\/li>\n
  6. Although VisualGDB can access the remote files directly over SSH, it is recommended to copy them locally if you want to use the profiler. This will help VisualGDB adjust the function locations reported by valgrind based on the actual function declarations:\"06-access\"<\/a><\/li>\n
  7. Proceed with the default settings on the last page:\"07-cmake\"<\/a><\/li>\n
  8. Press “Finish” to create the project. VisualGDB will automatically detect the targets declared in the original CMakeLists.txt file and show them in Solution Explorer:\"08-prj\"<\/a><\/li>\n
  9. The original CMakeLists.txt files don’t contain the targets for the benchmark. You can add it manually by right-clicking on the .vgdbcmake project and selecting “Add->New Items->Executable”. Add an executable called “benchmark” in the “benchmarks” subdirectory:\"10-bench\"<\/a><\/li>\n
  10. VisualGDB will automatically create the CMakeLists.txt file in that subdirectory. Remove the auto-generated source file and reference the benchmarks.cpp file instead:\"11-simple\"<\/a><\/li>\n
  11. Add “thirdparty\/benchpress” and “thirdparty\/cxxopts” to the include directories for the new target:\"12-dirs\"<\/a><\/li>\n
  12. Add “pthread” to the linked library names:\"13-pthread\"<\/a><\/li>\n
  13. To make profiling faster, we will comment out all benchmarks except “parse canada.json” and focus on optimizing the parser for this set. Build the target by selecting “Build Target(s)” in Solution Explorer:\"15-build\"<\/a><\/li>\n
  14. Ensure you have the RelWithDebInfo<\/strong> configuration selected. The regular Release<\/strong> configuration doesn’t generate debug symbols, so VisualGDB won’t be able to highlight performance of individual code lines:\"16-built\"<\/a><\/li>\n
  15. Open Debug Properties for the target and set the working directory to the “benchmarks” subdirectory:\"17-workdir\"<\/a><\/li>\n
  16. Run the program without debugger by pressing Ctrl-F5 and take note of the parsing time:\"18-time\"<\/a><\/li>\n
  17. Now we will begin optimizing the program performance. Select Analyze->Analyze Performance with VisualGDB:\"19-analyze\"<\/a>Ensure that the “benchmark” target is selected as the startup target, as VisualGDB always profiles the startup target.<\/li>\n
  18. Select “Profile without debugging” and press “OK”:\"20-start\"<\/a><\/li>\n
  19. VisualGDB will launch the benchmark under profiler and begin collecting performance data:\"21-recording\"<\/a><\/li>\n
  20. Once the profiling is complete, VisualGDB will automatically display function call tree sorted by the inclusive time. Expand the critical path until you see the “strtod” function. The function is responsible for parsing string representations of the floating point numbers (e.g. “1.2345”):\"22-critical\"<\/a><\/li>\n
  21. You can enter the total time observed without profiling in the “total time” field so that VisualGDB will try to estimate how much time each function would take under normal circumstances (without profiler). Note that this estimate is not 100% accurate as VisualGDB (and valgrind) counts CPU instructions that don’t always translate 1-to-1 to CPU cycles:\"23-times\"<\/a><\/li>\n
  22. A quick research<\/a> shows that the strtod() function is indeed relatively slow as it handles the advanced ‘E’ syntax. We will address this by replacing it with a simpler implementation handling normal cases that will fall back to calling strtod() if it encounters the ‘e’ character (the implementation is based on this one<\/a>). Create a file called “Optimizations.h” with the following contents:\n
    #pragma once\r\n#include <sys\/types.h>\r\n#include <string>\r\n#include <vector>\r\n\r\ndouble strtod_fast(const char *start, char **end)\r\n{\r\n\u00a0\u00a0\u00a0 const char *p = start;\r\n\u00a0\u00a0\u00a0 double r = 0.0;\r\n\u00a0\u00a0\u00a0 bool neg = false;\r\n\u00a0\u00a0\u00a0 if (*p == '-') {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 neg = true;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ++p;\r\n\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0\u00a0 while (*p >= '0' && *p <= '9') {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 r = (r * 10.0) + (*p - '0');\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ++p;\r\n\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0\u00a0 if (*p == '.') {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 double f = 0.0;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 double coef = 1.0;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ++p;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 while (*p >= '0' && *p <= '9') {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 f = (f * 10.0) + (*p - '0');\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ++p;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 coef \/= 10.0;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 r += f * coef;\r\n\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0\u00a0 if (neg) {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 r = -r;\r\n\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0\u00a0 if ((*p | 0x20) == 'e')\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 return strtod(start, end);\r\n\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0\u00a0 if (end)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 *end = const_cast<char *>(p);\r\n\u00a0\u00a0\u00a0 return r;\r\n}<\/pre>\n<\/li>\n
  23. Include the file from json.hpp and replace the call to std::strtod() with a call to strtod_fast():\"24-fast\"<\/a><\/li>\n
  24. Build the program and run it without debugging. See how the execution time got ~20% faster: \"25-newtime\"<\/a><\/li>\n
  25. Doing another profiling session will quickly reveal that strtod_fast()<\/strong> is indeed much faster than strtod()<\/strong> and now takes only 8% of the total program run time:\"26-newfunc\"<\/a><\/li>\n
  26. You can double-click on the function in the report and then click “annotate lines” to highlight performance of each individual line:\"27-lines\"<\/a>See how most of the time is spent parsing digits after the decimal point. If we wanted to optimize this function further, we could use a lookup table to handle 2 characters at once or try first converting all digits to an integral value and then dividing it in on FP operation.<\/li>\n
  27. Now we will show a few more optimizations. Enable the “show individual lines” switch and navigate to the “scan_number()” method. See that the “yytext.push_back()” line is now taking almost 20% of the entire program run time:\"28-pushback\"<\/a><\/li>\n
  28. Double-click on the line to open the corresponding source code. Note how yytext<\/strong> is defined as a string:\"29-yytext\"<\/a><\/li>\n
  29. As appending a character to it is considerably slowing down our program, we can replace it with a custom container optimized for quick appending characters one-by-one:\n