Submission of P1832R0

Author: John McFarlane

wg21/p1832.md

@@ -1,35 +1,36 @@
-**Document number**: D1832R0  
-**Date**: 2019-07-21  
+**Document number**: P1832R0  
+**Date**: 2019-08-05  
 **Reply-to**: John McFarlane, [[email protected]](mailto:[email protected])  
 **Audience**: SG6, SG14, SG15, SG19
 
 # Improving Debug Builds Inline With User Expectation
 
 ## Abstract
 
-Users frequently complain that modern C++ abstractions
+Some users complain that modern C++ abstractions
 make it hard to debug their programs.
-This document explores some of the reasons for these complaints and
+This document explores one of the reasons for these complaints and
 suggests a possible solution for implementers.
 
 ## Introduction
 
 This document is written in response to the assertion that
 "non-optimized build performance is important" as stated in the article,
 ["Modern" C++ Lamentations](https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/).
-The article, written by a game developer, sparked 
-[a discussion](https://groups.google.com/a/isocpp.org/d/topic/sg14/Zx3b2rgpYck/discussion)
-on the SG14 reflector which did not result in any action.
+The article, written by a game developer, sparked discussion
+on [social media](https://twitter.com/aras_p/status/1078682464602726400)
+and the [SG14 reflector](https://groups.google.com/a/isocpp.org/d/topic/sg14/Zx3b2rgpYck/discussion)
+which did not conclude with concrete action to be taken.
 
 More recently, SG6 and SG14 reviewed linear algebra papers in Cologne
 and game development was identified as a target audience for these
-library components. Without any further action to address the assertion,
+library components.
+I opined that without any further action to address the assertion,
 those components — and an increasing proportion of the standard library
-as a whole — will be ignored by a growing number of C++ users.
+as a whole — would be rejected by a growing number of C++ users.
 
-It is the author's view
-that the assertion forewarns of a scalability problem
-that C++ must address in order to remain relevant.
+It is my view that the assertion forewarns of a scalability problem
+that C++ must address in order to continue on its current course.
 
 ## Background
 
@@ -38,60 +39,60 @@ that C++ must address in order to remain relevant.
 During the development cycle, it is common for C++ users to produce
 binaries that are optimised for testing and debugging. These are often
 called *debug builds* — to be contrasted with *release builds* which
-are optimised for performance.
+are optimised for production use.
 
-It is accepted that the debug builds are bigger and execute more slowly
+It is accepted that debug builds are bigger and execute more slowly
 than release builds of the same program.
-They may include correctness checks, symbol information
-and debugging information.
+They may include correctness checks,
+and symbol and debugging information.
 They may also disable optimizations which
 hamper the compiler's ability to provide helpful debugging information.
 
 ### Function Inlining
 
 A very common optimization which causes the loss of debugging
-information is *function inlining*. Function inlining effectively
-removes functions and, in doing so, removes debugging information
-associated with those functions. In particular, **debug builds disable
-function inlining**.
+information is *function inlining*.
+Function inlining effectively removes functions
+and, in doing so, removes or obscures debugging information
+associated with those functions.
 
 The lack of function inlining is one reason why
 a debug build may be bigger and execute more slowly.
 
 ### Library-Based Abstractions
 
-Unfortunately, an increasing number of C++ abstractions rely heavily on
-function inlining in order to maintain zero run-time overhead.
-They are found in — both standard library implementations and —
-third-party libraries. They are characterised by
+Unfortunately, a growing number of library-based abstractions
+rely on function inlining in order to maintain zero run-time overhead.
+Many libraries are affected, including the standard library.
+The abstractions are characterised by
 deep call trees which collapse down to efficient machine code.
 
 ### The Dilemma
 
-Without function inlining, many library abstractions incur significant
+Without function inlining, these abstractions incur significant
 cost in terms of binary size and run-time performance.
 With function inlining, the same abstractions obfuscate
 stack traces and otherwise hamper the ability of tools to provide
 the user with helpful debugging information.
 
-This causes a dilemma which is felt most acutely in abstractions which
+This causes a dilemma which is felt most acutely in abstractions that
 have the highest ratio of compile-time complexity to run-time code
 generation.
 
-For example, many numerics libraries offer user-friendly abstractions
+For example, many numerics libraries offer abstractions
 over fundamental arithmetic types.
 A substantial amount of source code will routinely result in
 [a single arithmetic instruction](https://godbolt.org/z/easvxD).
-However, the problem is [ranges](https://godbolt.org/z/DHshRI)
+However, the problem [ranges](https://godbolt.org/z/DHshRI)
 far beyond purely arithmetic abstractions.
 
 ## Problem Analysis
 
 ### One User's Solution is Another User's Problem
 
-One way in which **library designers attempt to address concerns over
-performance** of debug builds is to try and single out their functions
-for inlining. **This fails** for two reasons.
+One way in which library designers attempt to address concerns over
+performance of debug builds is to try and single out their functions
+for inlining. This fails for two reasons.
 
 Firstly, explicit inlining as an optimization hint is a mistake.
 A modern tool chain does a far better job of determining
@@ -101,18 +102,18 @@ configuration and profile guidance. Assuming the user made the right
 choice on a given day (unlikely), the same choice may be wrong
 tomorrow.
 
-Secondly, **the intent to inline is based on ownership of the
-function**. It's likely that users of the library DO wish for
-inlining of its functions in debug builds. Conversely, authors of the
+Secondly, the intent to inline is based on ownership of the
+function. It's likely that *users* of the library DO wish for
+inlining of its functions in debug builds. Conversely, *authors* of the
 library DO NOT wish for inlining of the very same functions. Hence, no
 annotation or keyword could possibly cover both use cases.
 
 In short, explicit inlining is a bad tool for the wrong job.
 
-### A C++ Problem
+### One of Several Problems for C++
 
 A common feature of modern C++ functions is that they are delivered via
-header files. Equivalent traditional C++ and C functions would be
+header files. Comparable traditional C++ and C functions would be
 defined in source files, making it easy for the library author or
 library user to optimize them in isolation.
 
@@ -123,9 +124,17 @@ may habitually chose the 'step into' facility of the debugger and
 automatically traverse the subsection of the call graph that is under
 their control.
 
+This paper focuses on run-time performance of debug builds
+and not the quality of interactive debugging experience.
+However, it is a closely-related topic
+and this proposal hopes to improve it as a side effect.
+It has also been tackled by [IDEs](https://www.cprogramming.com/debugging/visual-studio-msvc-debugging-NoStepInto.html)
+and [GDB extensions](https://github.com/jefftrull/gdb_python_api)
+suggesting that is a problem worthy of attention in its own right.
+
 ### A Niche Problem
 
-The problem is not only a technical one. 
+The problem of debug build performance has a non-technical dimension. 
 
 Firstly, it affects programs where performance of debug builds is
 critical. This excludes batch programs and event-based user interfaces
@@ -134,44 +143,57 @@ where slower response to user input is not a deal-breaker.
 Secondly, it only affects developers who use debuggers. There is 
 [disagreement](https://twitter.com/PeterSommerlad/status/1078958027175329793)
 about whether interactive debugging is even necessary in the era of
-test-driven development. But it is clear that they are deemed necessary
-by users in specific domains and have been for a long time.
+test-driven development. But it is clear that it is deemed necessary
+by users in specific domains and has been for a long time.
 
-The necessity for interactive debugging in select domains and the
-reasons why this might pose a blind spot for the committee are not
-subjects covered here.
+It is plausible that developers
+who suffer most from debug build performance
+are not well represented within WG21.
+To them, the committee appears unsympathetic.
 
 ### Somebody Else's Problem
 
-Where the standard adds features which cause pain to users, it adds
-injury to describe those features as a 'quality of implementation'
-issue. That description is both true and inadequate.
-Not only does the committee have an obligation
+Where the standard adds features which cause pain to users,
+it adds insult to injury by describing those features
+as a 'quality of implementation' issue.
+That description is both accurate and inadequate.
+Not only does the committee have a responsibility
 to deal with the consequences of its choices.
-But it also has a unique ability to mediate between users and implementors.
-Hopeful this is role that SG15 can fulfil.
+But it also has a unique ability
+to mediate between users and implementors.
+Hopeful this is a role that SG15 can fulfil.
 
 ### Conclusion of Problem Analysis
 
-The direction C++ has been taking for a very long time is taking it in a
-direction which is causing some users an increasing number of
-productivity problems including:
+The course that C++ has been following for a long time
+takes it in a direction which is causing some users
+an increasing number of productivity problems including:
 
 1. slow, bloated debug builds;
-2. back traces that include unwanted noise from extra-project code; and
-3. hard-to-step-through call graphs.
-
-Function inlining largely addresses all of the above problems when
-applied to project dependencies at the expense of making 3) acute for
-the project code itself. This trade-off results in a dilemma.
-The author suggests that it is this dilemma which is the real problem.
+2. back traces that include unwanted noise from extra-project code;
+3. hard-to-step-through call graphs; and
+4. slow build times.
+
+Function inlining mitigates 1), 2) and 3)
+but can also adversely affect 1), 3) and 4).
+Thus the user faces a dilemma
+for which we offer no satisfactory solution.
+The author suggests that — aside from 4) which is an pressing issue in
+its own right — it is the dilemma which deserves attention and not
+individual problems, 1), 2) and 3).
 
 ## Straw Man Solution
 
-In order to stimulate discussion of a workable solution to The Dilemma,
-the following sub-section hypothesises a change to GCC (or Clang)
-which — if implementable — could provide a tool chain-only solution that
-could apply to existing source code unchanged.
+In order to stimulate discussion around
+a workable solution to the dilemma,
+the following sub-section hypothesises a change to popular tool chains
+which — if implementable — would provide
+an implementation-specific solution
+that could apply to existing source code unchanged.
+
+The solution works by considering pre-existing information about
+the origin of a function definition and using it to solve the dilemma
+of whether or not to inline that function.
 
 ### Proposed Change to GCC Option, `-Og`
 
@@ -228,8 +250,27 @@ headers.
 
 ## FAQ
 
+Q: How does the proposed tool chain enhancement help?
+
+A: It helps by drawing a distinction between the user's functions and
+   the functions of a user's dependencies. It is assumed that the user
+   only wishes to debug their own code and would rather optimise
+   dependency code. Dependency code should already be included in the
+   translation unit via a different header search path option. The
+   compiler can use that change to make the choice to inline. 
+
+Q: Does this proposal work?
+
+A: I have absolutely no idea. Optimising compilers are incredibly
+   sophisticated and complex tools which I haven't devoted the time to 
+   understand. It is entirely possible, for example, that the
+   architecture of a particular compiler makes it especially difficult
+   to selectively enable and disable inlining on a per-function basis.
+   But even if this technique worked half of the time, I posit that it
+   would improve the situation for users.
+
 Q: Why inlining, specifically, and not other optimizations which would
-   make code from dependencies faster?
+   make dependency code faster?
 
 A: For the sake of simplicity, this paper concentrates on what the
    author believes is the single most significant optimization