简体   繁体   English

为什么? 更改构建结构后,可执行文件的大小显着减少

[英]Why? Executable size cuts dramatically after changing build structure

I am on my personal C++ project that builds a simple compiler, called simplecc . 我在我的个人C ++项目中,该项目构建了一个简单编译器,称为simplecc Today, I triggered a refactor on it, which changed the way the main executable is built, or as I termed it, the build structure and the executable code size drops nearly a half. 今天,我触发了重构,从而改变了主要可执行文件的构建方式,或者正如我所说的那样,构建结构和可执行代码的大小减少了近一半。

My project has many components, such as the AST and CodeGen , which are named after their functionalities. 我的项目有很多组件,例如ASTCodeGen ,它们以其功能命名。 Each component resides in its own folder (both headers and cpp's do). 每个组件都位于其自己的文件夹中(标头和cpp都包含)。 There is a lib/ directory that holds directories for all other components and a CMakeList.txt in lib/ generates a single executable simplecc . 有一个lib/目录,其中包含所有其他组件的目录,并且lib/CMakeList.txt生成单个可执行文件simplecc Now here is the difference. 现在这是区别。

The old code: 旧代码:

# All source code is listed and directly built into the executable.
add_executable(simplecc
        Lex/Tokenize.cpp
        Lex/TokenInfo.cpp

        Parse/Grammar.cpp
        Parse/ASTBuilder.cpp
        Parse/Parser.cpp
        Parse/Node.cpp
        Parse/Parse.cpp
        Parse/ParseTreePrinter.cpp

        # More to come...
)

The new code: 新代码:

# lib/CMakeLists.txt
add_subdirectory(Lex)
add_subdirectory(Parse)
# More to come...

# Add main executable.
add_executable(simplecc Driver/main.cpp)

# Link to all components.
target_link_libraries(simplecc Driver)
# More to come.


# lib/Parse/CMakeLists.txt
add_library(Parse STATIC
        ASTBuilder.cpp
        Grammar.cpp
        Node.cpp
        Parse.cpp
        Parser.cpp
        ParseTreePrinter.cpp)

target_link_libraries(Parse Lex AST)

and within each sub-directory, a static library (archive) is built from the source of that component. 并且在每个子目录中,从该组件的源构建一个静态库(存档)。 Finally these archives are linked into the executable. 最后,这些归档文件被链接到可执行文件中。

While I think I just organized the code so that it is better tracked by cmake , it cut the code size of the executable dramatically! 虽然我认为我只是对代码进行了组织,以便可以通过cmake更好地进行跟踪,但它大大减少了可执行文件的代码大小! The old code is 14M and 3.7M after stripped. 剥离后的旧代码是14M和3.7M。 The new code is 2.4M before stripped 5.6M and 560K after stripped. 剥离后的新代码为2.4M,剥离后为5.6M,剥离后为560K。 How can this happen? 怎么会这样 It is generally true? 通常是真的吗? It is project-specific? 它是特定于项目的吗? My project makes use of CRTP extensively. 我的项目广泛使用CRTP

Edit : these data is derived from a Debug build. 编辑 :这些数据是从调试版本派生的。 I haven't done a Release build (will be added later). 我尚未完成发布版本(将在以后添加)。

The code size shrinks because some components are mistakenly omitted from main() and not linked in. No magic or secret. 由于某些组件被错误地从main()省略并且未链接进来,因此代码大小减小了。没有魔术或秘密。 Don't try to figure out any more. 不要试图找出更多。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 链接后最小的可执行文件大小 - Minimal executable size after linkage Microblaze & C++ | 为什么在某些条件下代码大小会急剧增加? - Microblaze & C++ | Why does the code size increase dramatically under certain conditions? 可执行文件在生成后缺少完整的库路径 - Executable missing full library path after build 为什么这个结构的大小是5,当它应该是4 - why size of this structure is 5 when it should be 4 WINAPI C / C ++ - >为什么二进制大小会急剧增加? (从VS2013切换到VS 2015) - WINAPI C/C++ -> why did the binary size increase dramatically ? (Switch from VS2013 to VS 2015) 为什么并行化会如此显着地降低性能? - Why would parallelization decrease performance so dramatically? 为什么结构数组的memset改变程序的行为? - Why memset of array of structure changing the program behaviour? libgnustl_shared.so来自哪里? 为什么建造后它的大小不同? - Where does libgnustl_shared.so come from? Why its size is different after I build? 在新版本的 Visual Studio 中构建后,可执行文件在 Azure 上无法正常工作 - Executable not working correctly on Azure after build in new version of Visual Studio 为什么可执行文件不可执行? - Why the executable is not executable?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM