C++ & OpenGL: a lot bigger size of executable, but not much more code
Greetings all,
I am following the OpenGL & C++ tutorials here: http://www.opengl-tutorial.org/
After finishing with first one and compiling the second one (on Windows 7, CodeBlocks MinGW), I got surprised by very much increased size of the executable.
For both projects I am linking GLFW and GLEW dynamically, and also adding libopengl32.a
The cpp file for first tutorial is here:
https://github.com/andersonfreitas/opengl-tutorial-org/blob/master/tutorial01_first_window/tutorial01.cpp
And the cpp + shaders for second tutorial are here:
https://github.com/andersonfreitas/opengl-tutorial-org/tree/master/tutorial02_red_triangle
The executable file size for 1st tutorial is 34kb, while for the 2nd tutorial it is 1.002kb.
Why such a big difference when compiling in same way and not adding a lot of additional code to the project? How can this be explained, or maybe even inspected? Thank you!
Kind regards,
T
I am following the OpenGL & C++ tutorials here: http://www.opengl-tutorial.org/
After finishing with first one and compiling the second one (on Windows 7, CodeBlocks MinGW), I got surprised by very much increased size of the executable.
For both projects I am linking GLFW and GLEW dynamically, and also adding libopengl32.a
The cpp file for first tutorial is here:
https://github.com/andersonfreitas/opengl-tutorial-org/blob/master/tutorial01_first_window/tutorial01.cpp
And the cpp + shaders for second tutorial are here:
https://github.com/andersonfreitas/opengl-tutorial-org/tree/master/tutorial02_red_triangle
The executable file size for 1st tutorial is 34kb, while for the 2nd tutorial it is 1.002kb.
Why such a big difference when compiling in same way and not adding a lot of additional code to the project? How can this be explained, or maybe even inspected? Thank you!
Kind regards,
T
closed account (N36fSL3A)
A size of 34 kb is quite trivial, so I'm not even sure why you're worrying about it.
The first thing I see is that the Glew library is actually being linked in the second example, whilst the compiler is optimizing it out in the first. While the headers were called in the first tutorial, the library wasn't actually being called, so the compiler didn't bother linking the library. However, now that the library is being called, the compiler couldn't get away with such an optimization.
Also, while a lot of code looks like it isn't being added, it is. For example, the LoadShader function that is called within the second example actually has its definition in a common folder, and as you can see, it isn't exactly small.
Another thing: Within that function, the standard library is being used quite a bit. With its generic template nature, it naturally generates a lot of code, so while it doesn't look like much, several hundred/thousands of lines are being generated behind the scenes. Take a peek at the vector header and string header. For every different type that is used in those classes, that same amount of code is generated. (There are plenty exceptions, but that's beyond the scope of what I'm willing to discuss right now, so that's just an elementary explanation. Take it with a grain of salt.) I imagine that that is a large factor as well.
Anyways, that's all I could gather within a few minutes of searching the code. I'm sure someone could point out more later on.
The first thing I see is that the Glew library is actually being linked in the second example, whilst the compiler is optimizing it out in the first. While the headers were called in the first tutorial, the library wasn't actually being called, so the compiler didn't bother linking the library. However, now that the library is being called, the compiler couldn't get away with such an optimization.
Also, while a lot of code looks like it isn't being added, it is. For example, the LoadShader function that is called within the second example actually has its definition in a common folder, and as you can see, it isn't exactly small.
Another thing: Within that function, the standard library is being used quite a bit. With its generic template nature, it naturally generates a lot of code, so while it doesn't look like much, several hundred/thousands of lines are being generated behind the scenes. Take a peek at the vector header and string header. For every different type that is used in those classes, that same amount of code is generated. (There are plenty exceptions, but that's beyond the scope of what I'm willing to discuss right now, so that's just an elementary explanation. Take it with a grain of salt.) I imagine that that is a large factor as well.
Anyways, that's all I could gather within a few minutes of searching the code. I'm sure someone could point out more later on.
Last edited on
That's right, 34 kb is alright, but 1 MB seemed too much given that there's not significantly more code involved (even if shader codes are added).
How can you tell from the code you see, that Glew is being linked in the second example, but not in the first? I see function "glewInit" being called in the first example.
I can see what you mean by vector and string headers. I really didn't imagine it could increase the size that much.
Thank you for explanation Fredbill 30
How can you tell from the code you see, that Glew is being linked in the second example, but not in the first? I see function "glewInit" being called in the first example.
I can see what you mean by vector and string headers. I really didn't imagine it could increase the size that much.
Thank you for explanation Fredbill 30
Last edited on
closed account (N36fSL3A)
You don't :) I skimmed right over that line and didn't see it.
I guess it could still be optimized out depending on the compiler, though. Is Glew statically or dynamically linked?
I guess it could still be optimized out depending on the compiler, though. Is Glew statically or dynamically linked?
Last edited on
| Another thing: Within that function, the standard library is being used quite a bit. With its generic template nature |
| it naturally generates a lot of code, so while it doesn't look like much, several hundred/thousands of lines are being generated behind the scenes. Take a peek at the vector header and string header. |
If a library is being linking statically, the linker may be able to remove functions that are unused in the first version. It may be the case that a single function causes a cascading effect, causing lots of other functions to get added to the final executable.
I linked both Glew and Glfw dynamically, at least I believe so! That's exactly what I was in doubt about after seeing 1 MB executable.
I added glew32.dll and glfw3.dll to project folder, and in linker settings added paths to glfw3dll.a and libglew32.dll.a.
This should be dynamically linked, right? Or is there another way for me to check also for future reference? :)
I added glew32.dll and glfw3.dll to project folder, and in linker settings added paths to glfw3dll.a and libglew32.dll.a.
This should be dynamically linked, right? Or is there another way for me to check also for future reference? :)
Last edited on
| Both sources are using pure C headers. |
Are they?
Check out <common/shader.cpp>. (Only in 2nd one)
https://github.com/huamulan/OpenGL-tutorial/blob/master/common/shader.cpp
Last edited on
Oh. Never mind, then.
Yes, #include <iostream> + MinGW = oddly large executable. MinGW has those idiosyncrasies.
Yes, #include <iostream> + MinGW = oddly large executable. MinGW has those idiosyncrasies.
Topic archived. No new replies allowed.