Functions had inline decision re-evaluated but remain unchanged

I'm working with C++ project. When I build a project in visual Studio Community 2017, a Visual studio C++ project generates a "1 functions had inline decision re-evaluated but remain unchanged".

So, What does mean by "1 functions had inline decision re-evaluated but remain unchanged"?

Does visual studio Community 2017 compiling my changes?

3 answers

  • answered 2018-04-17 05:49 colonel of truth

    A compiler may or may not inline a function depending on various factors, such as performance trade-offs, your compilation mode (e.g. release vs. debug), etc. This message is just the compiler being verbose and saying, "Hey I considered whether or not to inline 1 function, but left it the way it was before."

    While the message doesn't explicitly state it has compiled anything, the only reason for it reevaluate such a decision is due to either forcing recompilation, changing compilation settings, or, most often, a change to the source code.

  • answered 2018-04-17 05:49 xeco

    You can declare a function with the keyword inline and compiler replaces the function calls belong to that function with the function itself to reduce the execution time. However, the compiler can ignore the inline keyword if the function is too big, in this case, execution time increases. Also the compiler can inline a function if it is going to be more efficient even if you don't declare it as inline. In the end, the compiler decides to keep or remove this keyword. In your case, Visual Studio reevaluates the function to see if its decision should change. See here to understand better.

  • answered 2018-04-17 05:49 Matteo Italia

    Traditionally, the decision about what files to build after a change was based on the timestamp of each .cpp file and of its #included dependencies. If you touched a .h included by everyone in the project (even just to add a comment), all the files get rebuilt.

    Recent versions of VC++ have a Minimal Rebuild feature, that works at a smaller granularity: each function in a dependent .cpp file is re-examined, and, if the AST-level input to the compiler is unchanged, the code generated in the previous compilation for that function is recycled (see also this answer).

    Now, and here I'm speculating a bit, it may happen that the code generated in the previous run is legally ok, but something has changed about the inputs to the inlining heuristics.

    For example, imagine that there's some helper function foo that shrunk quite a bit from the last compilation, and it became eligible for inlining: the code generated for all the functions that call foo (which called it as a "regular" function, without inlining) can in fact be legally recycled and the resulting executable will run ok, although the compiler, if building everything from scratch, would now probably inline foo for better performance.

    With the minimal rebuild feature enabled, here the compiler privileges minimal rebuild time over best performance of the executable (and warns you about this).

    So, that message is generally nothing to worry about during the regular "compile-link-run-debug" cycle - if you are not investigating specifically performance issues, just enjoy your reduced compilation times.

    OTOH, if you need to make a "clean" or very-best performance release, either disable the minimal rebuild option, or just clean the build and rebuild from scratch; minimal rebuild will not kick in (as the files from the previous compilation will have been deleted) and you'll get the best performance from the generated executable.