{"id":1473,"date":"2013-06-12T13:00:00","date_gmt":"2013-06-12T13:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/vcblog\/2013\/06\/12\/optimizing-c-code-overview\/"},"modified":"2024-09-10T07:57:54","modified_gmt":"2024-09-10T07:57:54","slug":"optimizing-c-code-overview","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cppblog\/optimizing-c-code-overview\/","title":{"rendered":"Optimizing C++ Code : Overview"},"content":{"rendered":"

If you have arrived in the middle of this blog series, you might want instead to begin at the beginning<\/a>.<\/p>\n

This post explains the flow of data within the Visual C++ compiler – starting with our C++ source program, and ending with a corresponding binary program. This post is an easy one – dipping our toes into the shallow end of ocean.<\/p>\n

Let’s examine what happens when we compile a single-file program, stored in App.cpp<\/span>, from the command-line. (If you were to launch the compilation from within Visual Studio, the diagram below would have to include higher layers of software; however, these end up emitting the very commands I’m about to describe).<\/p>\n

So let’s imagine we just typed: CL \/O2 App.cpp<\/span><\/p>\n

The CL<\/span> stands from “Compile and Link”. \/O2<\/span> tells the compiler to optimize for speed – to generate machine code that runs as fast as possible. This command launches a process to execute the CL.EXE<\/span> program – a “driver” that calls several pieces of software: when joined together, they process the text in our App.cpp<\/span> and eventually generate a binary file, called App.exe<\/span>. When executed, this binary will carry out the operations we specified in our original source file.<\/p>\n

\"Image<\/a><\/p>\n

Let’s take a stroll around the diagram above and explain what’s going on.<\/p>\n

CL.EXE<\/span> parses our command-line, and checks that it makes sense. It then calls the C++ “front-end”, located in C1XX.DLL<\/span> (the “CXX” is meant to suggest “C++”, but dates back to a time when “+” was not a legal character in file names). The FrontEnd<\/span> is the part of the chain that understands <\/em>the C++ language. It scans, parses and transforms your App.cpp<\/span> into an equivalent tree, passed to the next component via 5 temporary files. The “language” represented by these 5 files is called “CIL”, for “C Intermediate Language”. Don’t confuse this with the intermediate code, generated by managed languages such as C#, sometimes called “MSIL” but also, unfortunately, named “CIL” in the ECMA-335<\/a> standard.<\/p>\n

Next, CL.EXE<\/span> calls the “back-end”, located in C2.DLL<\/span>. We call the BackEnd “UTC”, which stands for “Universal Tuple Compiler”, although this name doesn’t show up in any of the binaries included into Visual Studio. The BackEnd starts by converting the information from the FrontEnd into tuples – a binary stream of instructions. If we were to display them, they would look like a kind of high-level assembly language. It’s high-level in the senses that:<\/p>\n