{"id":3989,"date":"2018-05-23T12:05:44","date_gmt":"2018-05-23T19:05:44","guid":{"rendered":"https:\/\/visualgdb.com\/w\/?p=3989"},"modified":"2018-05-24T16:48:56","modified_gmt":"2018-05-24T23:48:56","slug":"using-live-profiling-to-analyze-critical-parts-of-linux-code","status":"publish","type":"post","link":"https:\/\/visualgdb.com\/tutorials\/profiler\/linux\/live\/","title":{"rendered":"Using Live Profiling to Analyze Critical Parts of Linux Code"},"content":{"rendered":"

This tutorial shows how to use the Live Profiling\u00a0for Linux programs to analyze the relative performance of the critical\u00a0code without slowing down the entire program. We will create a basic program that will be sorting an array of 10000 random numbers and will\u00a0use Live Profiling to quickly compare different\u00a0ways\u00a0of doing that without\u00a0profiling the entire program run.<\/p>\n

Before you begin, install Visual Studio and VisualGDB 5.3 or later.<\/p>\n

    \n
  1. Start Visual Studio and open the VisualGDB Linux Project Wizard:\"01-newprj\"<\/a><\/li>\n
  2. Select “Create a new project -> Application -> MSBuild”:\"02-msb\"<\/a><\/li>\n
  3. On the next page pick the remote\u00a0Linux machine you are targeting and click “Next”:\"03-remotehost\"<\/a><\/li>\n
  4. On the last page of the wizard proceed with the default file access options (Store locally & upload):\"04-access\"<\/a><\/li>\n
  5. Press “Finish” to create the project. Then replace the contents of the main file with the following code:\n
    #include <iostream>\r\n#include <vector>\r\n#include <stdio.h>\r\n#include <algorithm>\r\n\r\nusing namespace std;\r\n\r\nvoid TestSorting()\r\n{\r\n    std::vector<int> values;\r\n    for (int i = 0; i < 10000; i++)\r\n        values.push_back(rand());\r\n\r\n    std::sort(values.begin(), values.end());\r\n}\r\n\r\nint main(int argc, char *argv[])\r\n{\r\n    cout << \"Ready to test\";\r\n    TestSorting();\r\n    return 0;\r\n}<\/pre>\n<\/li>\n
  6. Build the solution via Ctrl-Shift-B and set a breakpoint on the std::sort() call:
    \n    \"05-build\"<\/a><\/li>\n
  7. Now we will use Live Profiling to automatically measure the exact time\u00a0taken by the sort() call (and highlight the critical path). VisualGDB will use this by automatically launching the valgrind tool behind the scenes and interpreting the profiling data it reports. Select Analyze -> Analyze Performance with VisualGDB:\"06-analyze\"<\/a><\/li>\n
  8. If you wanted to profile the entire program, you could simply select “Profile without debugging” or “Profile with debugging”, however this would result in a significant slowdown as the entire program execution would be\u00a0logged\u00a0in order to\u00a0analyze its performance. While this is acceptable for small programs, it could reduce the overall usability if the critical part of the code\u00a0is\u00a0not reached immediately. To\u00a0facilitate this scenario, VisualGDB provides the Live Profiling mode where it\u00a0will launch valrgind in the\u00a0suspended state and will only profile the code\u00a0once you explicitly\u00a0enable it. Select “Debug and get ready to profile” and click OK:
    \n    \"07-startprof\"<\/a><\/li>\n
  9. If your remote machine does not have valgrind installed, VisualGDB will offer installing it automatically:\"08-valgrind\"<\/a><\/li>\n
  10. Wait for the breakpoint to hit. Then locate the Live Profiling window and click “Start profiling”:\"09-start\"<\/a><\/li>\n
  11. Step over the call to std::sort() and click “Stop profiling & display results”:\"10-stop\"<\/a><\/li>\n
  12. VisualGDB will display the profiling results in the Live Profiling window.\u00a0In our example the call to std::sort() involved ~14M instructions mostly from __introsort_loop():\"11-stats\"<\/a><\/li>\n
  13. Now\u00a0we will see what happens if we\u00a0replace\u00a0std::sort() with the qsort() function from the standard C library:\n
    #include <stdlib.h>\r\nint CompareIntegers(const void * a, const void * b)\r\n{\r\n    return (*(int*)a - *(int*)b);\r\n}\r\n\r\nvoid TestSorting()\r\n{\r\n    \/\/...\r\n    qsort(values.data(), values.size(), sizeof(values[0]), CompareIntegers);\r\n}<\/pre>\n<\/li>\n
  14. Run the\u00a0live profiling again, enabling the actual profiling only for the qsort() call and observe that the sorting time is almost 3x less: \"12-qsort\"<\/a>Note that\u00a0each run of our program will generate exactly the same pseudo-random numbers, as we are not changing the random number generator seed by calling srand().<\/li>\n
  15. In this example the qsort() function works faster than std::sort() because it\u00a0is implemented in an external library (build with optimization),\u00a0while this std::sort() code is built in-place with no optimization. In order to compare the\u00a0optimized version of std::sort(), switch to the Release configuration and add asm(“nop”)<\/strong> statements around the call. Then set breakpoints in both statements and\u00a0run the profiling between the breakpoint hits:\"13-faster\"<\/a><\/li>\n
  16. Notice how the sorting time has further decreased and 22% of if was taken by the TestSorting() function itself. This happens because most of the std::sort() logic was inlined and fine-tuned for this specific\u00a0use case (e.g. it will do the integer comparison in-place instead of\u00a0calling the user-provided callback like qsort() does). You can confirm this by switching to the Disassembly view:\"14-inlined\"<\/a><\/li>\n
  17. Finally try replacing the vector with a list and check whether the sorting time changes:\"15-list\"<\/a>See how the sorting time\u00a0increased as\u00a0updating a linked list involves more memory operations than updating a consecutive array.<\/li>\n<\/ol>\n
    You can\u00a0turn the profiling on and off\u00a0multiple times during a debug session. Each time you turn it on, VisualGDB will activate the valgrind profiling logic,\u00a0collecting\u00a0the\u00a0detailed\u00a0statistics about the executed code, and each time you turn it off, valgrind will be put into inactive state,\u00a0reducing the slowdown of your application. You can effectively use this technique to profile critical parts of large programs without slowing down the entire program.<\/p>\n","protected":false},"excerpt":{"rendered":"
    This tutorial shows how to use the Live Profiling\u00a0for Linux programs to analyze the relative performance of the critical\u00a0code without<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[152],"tags":[33,109,153],"_links":{"self":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3989"}],"collection":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/comments?post=3989"}],"version-history":[{"count":1,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3989\/revisions"}],"predecessor-version":[{"id":4005,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/posts\/3989\/revisions\/4005"}],"wp:attachment":[{"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/media?parent=3989"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/categories?post=3989"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/visualgdb.com\/w\/wp-json\/wp\/v2\/tags?post=3989"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}