{"id":26104,"date":"2020-05-28T14:00:50","date_gmt":"2020-05-28T14:00:50","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cppblog\/?p=26104"},"modified":"2020-05-28T13:49:07","modified_gmt":"2020-05-28T13:49:07","slug":"profiling-template-metaprograms-with-cpp-build-insights","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/profiling-template-metaprograms-with-cpp-build-insights\/","title":{"rendered":"Profiling template metaprograms with C++ Build Insights"},"content":{"rendered":"

The use of templates in C++ programs can sometimes lead to longer builds. C++ Build Insights puts tools at your disposal for analyzing template usage patterns and their associated impact on build time. In this article, we show you how to use the vcperf analysis tool<\/a> and the C++ Build Insights SDK<\/a> to understand and fix problematic template patterns. We demonstrate the practical use of these tools through a case study in which we reduced build time for the Sprout open-source metaprogramming library by 25%. We hope these methods will help you approach your template endeavors with confidence!<\/p>\n

How to obtain and use vcperf<\/strong><\/span><\/p>\n

The examples in this article make use of vcperf<\/em>, a tool that allows you to capture a trace of your build and to view it in the Windows Performance Analyzer (WPA)<\/a>. The latest version is available in Visual Studio 2019.<\/p>\n

1. Follow these steps to obtain and configure vcperf <\/em>and WPA:<\/strong><\/span><\/p>\n

    \n
  1. Download and install the latest Visual Studio 2019<\/a>.<\/li>\n
  2. Obtain WPA by downloading and installing the latest Windows ADK<\/a>.<\/li>\n
  3. Copy the perf_msvcbuildinsights.dll<\/em> file from your Visual Studio 2019\u2019s MSVC installation directory to your newly installed WPA directory. This file is the C++ Build Insights WPA add-in, which must be available to WPA for correctly displaying the C++ Build Insights events.\n
      \n
    1. MSVC\u2019s installation directory is typically: C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\{<\/span>Edition<\/span>}<\/span>\\VC\\Tools\\MSVC\\{Version}\\bin\\Hostx64\\x64<\/code>.<\/li>\n
    2. WPA\u2019s installation directory is typically: C:\\Program Files (x86)\\Windows Kits\\10\\Windows Performance Toolkit<\/code>.<\/li>\n<\/ol>\n<\/li>\n
    3. Open the perfcore.ini<\/em> file in your WPA installation directory and add an entry for the perf_msvcbuildinsights.dll<\/em> file. This tells WPA to load the C++ Build Insights add-in on startup.<\/li>\n<\/ol>\n

      You can also obtain the latest vcperf<\/em> and WPA add-in by cloning and building the vcperf GitHub repository<\/a>. Feel free to use your built copy in conjunction with Visual Studio 2019!<\/p>\n

      2. Follow these steps to collect a trace of your build:<\/strong><\/span><\/p>\n

        \n
      1. Open an elevated x64 Native Tools Command Prompt for VS 2019<\/em><\/strong>.<\/li>\n
      2. Obtain a trace of your build:\n
          \n
        1. Run the following command: vcperf \/start \/level3 MySessionName<\/code>. The \/level3<\/code> option enables the collection of template events.<\/li>\n
        2. Build your C++ project from anywhere, even from within Visual Studio (vcperf<\/em> collects events system-wide).<\/li>\n
        3. Run the following command: vcperf \/stop \/templates MySessionName outputFile.etl<\/code>. This command will stop the trace, analyze all events, including template events, and save everything in the outputFile.etl<\/em> trace file.<\/li>\n<\/ol>\n<\/li>\n
        4. Open the trace you just collected in WPA.<\/li>\n<\/ol>\n

          Viewing template information in WPA<\/strong><\/span><\/p>\n

          The most time-consuming activity related to templates for the compiler is to instantiate them. C++ Build Insights provides a WPA view called Template Instantiations<\/em><\/strong> that allows you to see the instantiation time of the top templates in your program. After opening your trace in WPA, you can open this view by dragging it from the Graph Explorer<\/em><\/strong> pane to the Analysis<\/em><\/strong> window, as shown below.<\/p>\n

          \"Image<\/p>\n

          A note on the presence of template events in a vcperf trace and WPA<\/strong><\/span><\/p>\n

          If you do not see a Template Instantiations<\/em><\/strong> view in the Graph Explorer<\/em><\/strong> pane, make sure that you have completed the WPA configuration steps from the How to obtain and use vcperf<\/em><\/strong> section correctly, and that you have passed the right arguments to vcperf<\/em> when starting and stopping your trace.<\/p>\n

          For scalability reasons, vcperf<\/em> only writes in the output trace the templates that take the most time to instantiate in your build. If template instantiations were not a significant factor in your build times, vcperf<\/em> will omit template information, and the Template Instantiations<\/em><\/strong> view will not appear.<\/p>\n

          Case study: speeding up the Sprout template metaprogramming library<\/strong><\/span><\/p>\n

          In this case study, we use a real open source project from GitHub to show how you can use vcperf<\/em> and WPA to diagnose and treat long build times in template metaprogramming code. Specifically, we demonstrate how we’ve used these tools to reduce the build time for the Sprout library by around 25%.<\/p>\n

          Use these steps if you would like to follow along:<\/p>\n

            \n
          1. Clone the Sprout C++ Libraries repository<\/a> from GitHub.<\/li>\n
          2. Checkout the following commit: 6b5addba9face0a<\/code>.<\/li>\n
          3. Obtain a trace for a full rebuild of the Sprout tests:\n
              \n
            1. Open an elevated x64 Native Tools Command Prompt for VS 2019.<\/em><\/strong><\/li>\n
            2. Run the following command: vcperf \/start \/level3 Sprout<\/code><\/li>\n
            3. Build the Sprout tests by running the following command: cl \/std:c++latest \/D_HAS_DEPRECATED_IS_LITERAL_TYPE=1 \/D_SILENCE_CXX17_IS_LITERAL_TYPE_DEPRECATION_WARNING \/EHsc \/I. \/constexpr:steps100000000 .\\testspr\\sprout.cpp<\/code>.<\/li>\n
            4. Run the following command: vcperf \/stop \/templates Sprout sprout.etl<\/code>. This will save a trace of the build in sprout.etl<\/em>. The trace will contain template information.<\/li>\n<\/ol>\n<\/li>\n
            5. Open the trace in WPA.<\/li>\n<\/ol>\n

              We open the Build Explorer<\/em><\/strong> and Template Instantiations<\/em><\/strong> views one on top of the other. The Build Explorer<\/em><\/strong> view indicates that the build lasted around 13.5 seconds. This can be seen by looking at the time axis at the bottom of the view (labeled A). The Template Instantiations<\/em><\/strong> view shows a locus of condensed template instantiation activity somewhere between time 8 and 10.5 (labeled B).<\/p>\n

              \"Image<\/p>\n

              By default, all template specializations are grouped by the primary template\u2019s name. For example, the std::vector<int><\/code> and std::vector<double><\/code> specializations would both be grouped under the std::vector<\/code> primary template name. In our case, we would like to know if there is one specialization in particular that causes an issue, so we reorganize the view\u2019s columns such that the entries are grouped by Specialization Name<\/em><\/strong> instead. This operation is shown below.<\/p>\n

              \"Image<\/p>\n

              We notice that there is one large instantiation of the sprout::tpp::all_of<\/code> template that is responsible for around 2.15 seconds. There are also 511 instantiations of sprout::tpp::detail::all_of_impl<\/code>. We surmise that sprout::tpp::all_of<\/code> is a root template that calls into a highly recursive sprout::tpp::detail::all_of_impl<\/code> template. This discovery is shown below.<\/p>\n

              \"Image<\/p>\n

              Investigating the codebase<\/strong><\/span><\/p>\n

              We find that the culprit sprout::tpp::all_of<\/code> template instantiation is triggered by a call to operator()<\/code> of the following type in sprout\\random\\shuffle_order.hpp<\/em>:<\/p>\n

              typedef sprout::random::shuffle_order_engine<\r\n    sprout::random::minstd_rand0, 256> knuth_b;<\/pre>\n
              This type internally contains a compile-time array of 256 elements, which ends up being passed to the default_remake_container<\/code> function in the sprout\\container\\container_construct_traits.hpp<\/em> header. This function has the following three template definitions. Function bodies have been replaced with comments for simplicity.<\/p>\n
              template<typename Container, typename Cont, typename... Args>\r\ninline SPROUT_CONSTEXPR typename std::enable_if<\r\n    sprout::is_fixed_container<Container>::value,\r\n    typename sprout::container_construct_traits<Container>::copied_type\r\n>::type\r\ndefault_remake_container(Cont&&, \r\n    typename sprout::container_traits<Container>::difference_type, \r\n    Args&&... args) \r\n{\r\n    \/\/ Default case\r\n}\r\n\r\ntemplate<typename Container, typename Cont, typename... Args>\r\ninline SPROUT_CONSTEXPR typename std::enable_if<\r\n    !sprout::is_fixed_container<Container>::value\r\n        && !(sizeof...(Args) == 2 && sprout::tpp::all_of<\r\n                sprout::is_input_iterator<\r\n                    typename std::remove_reference<Args>::type>...>::value)\r\n        ,\r\n    typename sprout::container_construct_traits<Container>::copied_type\r\n>::type\r\ndefault_remake_container(Cont&&, \r\n    typename sprout::container_traits<Container>::difference_type, \r\n    Args&&... args) \r\n{\r\n    \/\/ Default case\r\n}\r\n\r\ntemplate<typename Container, typename Cont, typename InputIterator>\r\ninline SPROUT_CONSTEXPR typename std::enable_if<\r\n    !sprout::is_fixed_container<Container>::value,\r\n    typename sprout::container_construct_traits<Container>::copied_type\r\n>::type\r\ndefault_remake_container(Cont&& cont, \r\n    typename sprout::container_traits<Container>::difference_type, \r\n    InputIterator first, InputIterator last) \r\n{\r\n    \/\/ Special case when we have a non-fixed container with 2\r\n    \/\/ input iterator args.\r\n}<\/pre>\n
              These definitions are all enabled or disabled based on certain conditions using the std::enable_if<\/code> standard type traits class. Can you spot the sprout::tpp::all_of<\/code> call in the second definition\u2019s std::enable_if<\/code> condition? We replicate it below:<\/p>\n
              !(sizeof...(Args) == 2 && \r\n    sprout::tpp::all_of<sprout::is_input_iterator<\r\n        typename std::remove_reference<Args>::type>...>::value)<\/pre>\n
              Looking at the condition as a whole, we can see that sprout::tpp::all_of<\/code> does not need to be evaluated if default_remake_container<\/code> is called with a number of arguments different from 2. In our case we have 256 arguments and we know that the condition will be false regardless of what sprout::tpp::all_of<\/code> returns. In the eyes of the compiler, this does not matter. It will still evaluate sprout::tpp::all_of<\/code> on our 256 arguments when trying to resolve the call to default_remake_container<\/code>, resulting in a large, time-consuming recursive template instantiation.<\/p>\n
              Finding a new solution<\/strong><\/span><\/p>\n
              We fix this situation by adding a level of indirection between default_remake_container<\/code> and the sprout::tpp::all_of<\/code> call. We first branch on the number of arguments:<\/p>\n
              template<typename Container, typename Cont, typename... Args>\r\ninline SPROUT_CONSTEXPR typename std::enable_if<\r\n    sizeof...(Args) == 2,\r\n    typename sprout::container_construct_traits<Container>::copied_type\r\n>::type\r\ndefault_remake_container(Cont&& cont, \r\n    typename sprout::container_traits<Container>::difference_type, \r\n    Args&&... args) \r\n{\r\n    return default_remake_container_two_args<Container>(\r\n        SPROUT_FORWARD(Cont, cont), SPROUT_FORWARD(Args, args)...);\r\n}\r\n\r\ntemplate<typename Container, typename Cont, typename... Args>\r\ninline SPROUT_CONSTEXPR typename std::enable_if<\r\n    sizeof...(Args) != 2,\r\n    typename sprout::container_construct_traits<Container>::copied_type\r\n>::type\r\ndefault_remake_container(Cont&& cont, \r\n    typename sprout::container_traits<Container>::difference_type, \r\n    Args&&... args) \r\n{\r\n    \/\/ Default case\r\n}<\/pre>\n
              Only when an argument count of 2 is confirmed do we evaluate sprout::tpp::all_of<\/code> through a new function called default_remake_container_two_args<\/code>:<\/p>\n
              template<typename Container, typename Cont, typename... Args>\r\ninline SPROUT_CONSTEXPR typename std::enable_if<\r\n    sprout::is_fixed_container<Container>::value || \r\n        !sprout::tpp::all_of<sprout::is_input_iterator<\r\n            typename std::remove_reference<Args>::type>...>::value\r\n        ,\r\n    typename sprout::container_construct_traits<Container>::copied_type\r\n>::type\r\ndefault_remake_container_two_args(Cont&&, Args&&... args) {\r\n    \/\/ Default case\r\n}\r\n\r\ntemplate<typename Container, typename Cont, typename InputIterator>\r\ninline SPROUT_CONSTEXPR typename std::enable_if<\r\n    !sprout::is_fixed_container<Container>::value,\r\n    typename sprout::container_construct_traits<Container>::copied_type\r\n>::type\r\ndefault_remake_container_two_args(Cont&& cont, \r\n    InputIterator first, InputIterator last) \r\n{\r\n    \/\/ Special case when we have a non-fixed container with 2 \r\n    \/\/ input iterator args.\r\n}<\/pre>\n
              You can see the full details of this code change in our fork on GitHub<\/a>.<\/p>\n
              Evaluating the final result<\/strong><\/span><\/p>\n
              After fixing the code, we collect a second trace of the compilation using the same steps that we covered at the beginning of the case study. We notice that the build time has decreased by around 25% to a total of approximately 9.7 seconds. The Template Instantiations view is also gone, meaning that template instantiations are no longer an issue in this build. Victory!<\/p>\n
              \"Image<\/p>\n
              Identifying problematic template instantiations using the C++ Build Insights SDK<\/strong><\/span><\/p>\n
              Recursive, time-consuming template instantiations are not an uncommon problem in codebases that use template metaprogramming, so we want to identify these problems faster in the future without having to go through the hassle of launching WPA and inspecting a trace manually. Luckily, most analysis tasks performed manually with vcperf<\/em> and WPA can also be performed programmatically using the C++ Build Insights SDK. To illustrate this point, we\u2019ve prepared the RecursiveTemplateInspector<\/em><\/strong> SDK sample. It prints out the most time-consuming template instantiation hierarchies in a build, along with statistics about them such as recursion tree depth, total number of instantiations and the root specialization name that started it all.<\/p>\n
              Let\u2019s repeat the Sprout case study from the previous section, but this time by using the RecursiveTemplateInspector <\/em><\/strong>to see what it finds. <\/em>Use these steps if you want to follow along:<\/p>\n
                \n
              1. Clone the C++ Build Insights SDK samples GitHub repository<\/a> on your machine.<\/li>\n
              2. Build the Samples.sln <\/em><\/strong>solution, targeting the desired architecture (x86 or x64), and using the desired configuration (debug or release). The sample\u2019s executable will be placed in the out\/{architecture}\/{configuration}\/RecursiveTemplateInspector folder, starting from the root of the repository.<\/li>\n
              3. Follow the steps from the Case study: speeding up a template metaprogramming library<\/em><\/strong> section to collect a trace of the Sprout compilation. Use the vcperf \/stopnoanalyze Sprout sprout-raw.etl<\/code> command instead of the \/stop<\/code> command when stopping your trace.<\/li>\n
              4. Pass the sprout-raw.etl<\/em> trace as the first argument to the RecursiveTemplateInspector<\/em><\/strong> executable.<\/li>\n<\/ol>\n
                As shown below, RecursiveTemplateInspector<\/em><\/strong> correctly identifies the sprout::tpp::all_of<\/code> template instantiation that has been causing us problems, which triggers other instantiations recursively for a total of 4043 instantiations.<\/p>\n
                \"Image<\/p>\n
                Rerunning RecursiveTemplateInspector <\/em><\/strong>on our fixed codebase shows that all problematic template instantiations are gone. The ones that remain have a low duration and can be ignored.<\/p>\n
                \"Image<\/p>\n
                Understanding the sample code<\/strong><\/span><\/p>\n
                We first filter all stop activity and simple events by asking the C++ Build Insights SDK to forward what we need to the OnTemplateRecursionTreeBranch<\/code>, and OnSymbolName<\/code> functions. The name of the functions has no effect on how the C++ Build Insights SDK will filter the events; only their parameters matter. Continue reading to understand what is actually being filtered.<\/p>\n
                AnalysisControl OnStopActivity(const EventStack& eventStack)\r\n    override\r\n{\r\n    MatchEventStackInMemberFunction(eventStack, this,\r\n        &RecursiveTemplateInspector::OnTemplateRecursionTreeBranch);\r\n\r\n    return AnalysisControl::CONTINUE;\r\n}\r\n\r\nAnalysisControl OnSimpleEvent(const EventStack& eventStack)\r\n    override\r\n{\r\n    MatchEventStackInMemberFunction(eventStack, this,\r\n        &RecursiveTemplateInspector::OnSymbolName);\r\n\r\n    return AnalysisControl::CONTINUE;\r\n}<\/pre>\n
                We use the OnTemplateRecursionTreeBranch<\/code> function to capture each branch of the template instantiation recursion tree one by one. Because C++ Build Insights events are represented as stacks, capturing recursive relationships between events is something that can be done with little effort. The TemplateInstantiationGroup<\/code> capture class automatically unwinds the event stack, and presents all template instantiations that occurred in the parsing thread as a vector-like C++ container ordered from root to leaf. Because we tied the OnTemplateRecursionTreeBranch<\/code> function to the stop activity event, we will always receive the branches in a given recursion tree at the point where the parsing thread is coming back from the deepest level. We take advantage of this fact to compute the maximum depth of the recursion tree as we process all its branches. Once the root instantiation itself reaches its stop event, we wrap up the instantiation tree by storing the total instantiation time for the tree, along with the translation unit in which it occurred.<\/p>\n
                void OnTemplateRecursionTreeBranch(FrontEndPass fe, \r\n    TemplateInstantiationGroup recursionTreeBranch)\r\n{\r\n    const TemplateInstantiation& root = recursionTreeBranch[0];\r\n    const TemplateInstantiation& current = recursionTreeBranch.Back();\r\n\r\n    auto& info = rootSpecializations_[root.SpecializationSymbolKey()];\r\n\r\n    auto& visitedSet = info.VisitedInstantiations;\r\n\r\n    if (visitedSet.find(current.EventInstanceId()) == visitedSet.end())\r\n    {\r\n        \/\/ We have a new unvisited branch. Update the max depth of the\r\n        \/\/ recursion tree.\r\n\r\n        info.MaxDepth = std::max(info.MaxDepth, recursionTreeBranch.Size());\r\n\r\n        for (size_t idx = recursionTreeBranch.Size(); idx-- > 0;)\r\n        {\r\n            const TemplateInstantiation& ti = recursionTreeBranch[idx];\r\n\r\n            auto p = visitedSet.insert(ti.EventInstanceId());\r\n\r\n            bool wasVisited = !p.second;\r\n\r\n            if (wasVisited)\r\n            {\r\n                \/\/ Stop once we reach a visited template instantiation,\r\n                \/\/ because its parents will also have been visited.\r\n                break;\r\n            }\r\n\r\n            ++info.InstantiationCount;\r\n        }\r\n    }\r\n\r\n    if (recursionTreeBranch.Size() != 1) {\r\n        return;\r\n    }\r\n\r\n    \/\/ The end of a hierarchy's instantiation corresponds to the stop\r\n    \/\/ event of the root specialization's instantiation. When we reach\r\n    \/\/ that point, we update the total instantiation time of the hierarchy.\r\n\r\n    info.TotalInstantiationTime = root.Duration();\r\n\r\n    info.File = fe.InputSourcePath() ? fe.InputSourcePath() :\r\n        fe.OutputObjectPath();\r\n\r\n    visitedSet.clear();\r\n}<\/pre>\n
                Template instantiation events don\u2019t contain the name of the symbol that was instantiated. Deriving the name is a costly operation, and doing so while measuring an instantiation would skew the time measurement. Instead, a numeric key is issued, which we can later use to match with the appropriate name by listening to the SymboName<\/code> event. The OnSymbolName<\/code> function does just that, and stores the name of every root template instantiation.<\/p>\n
                void OnSymbolName(SymbolName symbolName)\r\n{\r\n    auto it = rootSpecializations_.find(symbolName.Key());\r\n\r\n    if (it == rootSpecializations_.end()) {\r\n        return;\r\n    }\r\n\r\n    it->second.RootSpecializationName = symbolName.Name();\r\n}<\/pre>\n
                At the end of our analysis, we traverse all root template instantiations, sort them by longest duration, and dump the top ones.<\/p>\n
                AnalysisControl OnEndAnalysis() override\r\n{\r\n    using namespace std::chrono;\r\n\r\n    auto topSpecializations = GetTopInstantiations();\r\n    \r\n    if (specializationCountToDump_ == 1) {\r\n        std::cout << \"Top template instantiation hierarchy:\";\r\n    }\r\n    else {\r\n        std::cout << \"Top \" << specializationCountToDump_ << \r\n            \" template instantiation \" << \"hierarchies\";\r\n    }\r\n        \r\n    std::cout << std::endl << std::endl;\r\n\r\n    for (auto& info : topSpecializations)\r\n    {\r\n        std::wcout << \"File:           \" << \r\n            info.File << std::endl;\r\n        std::cout  << \"Duration:       \" << \r\n            duration_cast<milliseconds>(\r\n                info.TotalInstantiationTime).count() << \r\n            \" ms\" << std::endl;\r\n        std::cout  << \"Max Depth:      \" << \r\n            info.MaxDepth << std::endl;\r\n        std::cout  << \"Instantiations: \" << \r\n            info.InstantiationCount << std::endl;\r\n        std::cout  << \"Root Name:      \" << \r\n            info.RootSpecializationName << std::endl << std::endl;\r\n    }\r\n\r\n    return AnalysisControl::CONTINUE;\r\n}<\/pre>\n
                Tell us what you think!<\/strong><\/span><\/p>\n
                We hope the information in this article has helped you understand how you can use the tools provided by C++ Build Insights to profile your usage of templates.<\/p>\n
                Give vcperf<\/em> a try today by downloading the latest version of Visual Studio 2019<\/a>, or by cloning the tool directly from the vcperf Github repository<\/a>. Try out the RecursiveTemplateInspector<\/em><\/strong> sample from this article by cloning the C++ Build Insights samples repository<\/a> from GitHub, or refer to the official C++ Build Insights SDK documentation<\/a> to build your own analysis tools.<\/p>\n
                Have you found problematic template instantiations using vcperf<\/em> or the C++ Build Insights SDK? Let us know in the comments below, on Twitter (@VisualC<\/a>), or via email at visualcpp@microsoft.com<\/a>.<\/p>\n
                 <\/p>\n
                This article contains code snippets from Sprout<\/a>, Copyright (c) 2011-2019 Bolero MURAKAMI, distributed under the Boost Software License, Version 1.0<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"
                The use of templates in C++ programs can sometimes lead to longer builds. C++ Build Insights puts tools at your disposal for analyzing template usage patterns and their associated impact on build time. In this article, we show you how to use the vcperf analysis tool and the C++ Build Insights SDK to understand and […]<\/p>\n","protected":false},"author":6966,"featured_media":26128,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1,239],"tags":[],"class_list":["post-26104","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cplusplus","category-diagnostics"],"acf":[],"blog_post_summary":"
                The use of templates in C++ programs can sometimes lead to longer builds. C++ Build Insights puts tools at your disposal for analyzing template usage patterns and their associated impact on build time. In this article, we show you how to use the vcperf analysis tool and the C++ Build Insights SDK to understand and […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/26104","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/users\/6966"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/comments?post=26104"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/posts\/26104\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media\/26128"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/media?parent=26104"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/categories?post=26104"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/cppblog\/wp-json\/wp\/v2\/tags?post=26104"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}