Why does the program size remain unchanged when more variables and/or instructions are added?
I started with an "empty" program and checked the size of the .exe file produced
int main()
{
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
I then added a large array of static variables
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimised away and (b) see if the extra instructions would increase the number of bytes of the .exe
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
Literally not a single byte more. At this point my (stab in the dark) guess is that the .exe requests the OS to allocate the correct amount of memory needed for the static variables when the program starts but this doesn't seem right. What determines the .exe file size?
c++ memory compilation static
|
show 4 more comments
I started with an "empty" program and checked the size of the .exe file produced
int main()
{
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
I then added a large array of static variables
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimised away and (b) see if the extra instructions would increase the number of bytes of the .exe
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
Literally not a single byte more. At this point my (stab in the dark) guess is that the .exe requests the OS to allocate the correct amount of memory needed for the static variables when the program starts but this doesn't seem right. What determines the .exe file size?
c++ memory compilation static
3
Why doesn't it seem right to you that the OS would allocate memory for the program's variables? The storage for the variables is not actually inside the executable ... imagine the executable is on a read-only hard disk for example, or if it's launched twice
– M.M
Nov 22 '18 at 21:17
How are you compiling the code? How are you determining the file size? Are you looking at size on disk? It might be rounding up to a cluster size (see this explanation). Are you sure you aren't accidentally looking at the same file three times? Maybe the other examples failed to compiled or compiled to another file.
– François Andrieux
Nov 22 '18 at 21:19
@M.M Mostly because I have noticed that more complex programs tend to have larger .exe files. Also (less sure but) because I am not sure how the program would know how much memory to allocate, for example, if I have 2 functions that each have a large static arrays and at runtime I select one of the functions to call randomly then one of the static arrays will never be instantiated.
– CanISleepYet
Nov 22 '18 at 21:23
@FrançoisAndrieux I am compiling on MSVC in Debug with default settings. You are correct that perhaps this is the problem. Yes I checked that the .exe was modified each time.
– CanISleepYet
Nov 22 '18 at 21:26
@JesperJuhl So you are saying that (in general and for more realistic examples) you would expect the size of the .exe to increase as more instructions and variables are added but this increase will not be linear depending on what optimizations the compiler can make?
– CanISleepYet
Nov 22 '18 at 21:27
|
show 4 more comments
I started with an "empty" program and checked the size of the .exe file produced
int main()
{
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
I then added a large array of static variables
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimised away and (b) see if the extra instructions would increase the number of bytes of the .exe
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
Literally not a single byte more. At this point my (stab in the dark) guess is that the .exe requests the OS to allocate the correct amount of memory needed for the static variables when the program starts but this doesn't seem right. What determines the .exe file size?
c++ memory compilation static
I started with an "empty" program and checked the size of the .exe file produced
int main()
{
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
I then added a large array of static variables
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimised away and (b) see if the extra instructions would increase the number of bytes of the .exe
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Exe Size: 58.5 KB (59,904 bytes)
Literally not a single byte more. At this point my (stab in the dark) guess is that the .exe requests the OS to allocate the correct amount of memory needed for the static variables when the program starts but this doesn't seem right. What determines the .exe file size?
c++ memory compilation static
c++ memory compilation static
asked Nov 22 '18 at 21:13
CanISleepYetCanISleepYet
282
282
3
Why doesn't it seem right to you that the OS would allocate memory for the program's variables? The storage for the variables is not actually inside the executable ... imagine the executable is on a read-only hard disk for example, or if it's launched twice
– M.M
Nov 22 '18 at 21:17
How are you compiling the code? How are you determining the file size? Are you looking at size on disk? It might be rounding up to a cluster size (see this explanation). Are you sure you aren't accidentally looking at the same file three times? Maybe the other examples failed to compiled or compiled to another file.
– François Andrieux
Nov 22 '18 at 21:19
@M.M Mostly because I have noticed that more complex programs tend to have larger .exe files. Also (less sure but) because I am not sure how the program would know how much memory to allocate, for example, if I have 2 functions that each have a large static arrays and at runtime I select one of the functions to call randomly then one of the static arrays will never be instantiated.
– CanISleepYet
Nov 22 '18 at 21:23
@FrançoisAndrieux I am compiling on MSVC in Debug with default settings. You are correct that perhaps this is the problem. Yes I checked that the .exe was modified each time.
– CanISleepYet
Nov 22 '18 at 21:26
@JesperJuhl So you are saying that (in general and for more realistic examples) you would expect the size of the .exe to increase as more instructions and variables are added but this increase will not be linear depending on what optimizations the compiler can make?
– CanISleepYet
Nov 22 '18 at 21:27
|
show 4 more comments
3
Why doesn't it seem right to you that the OS would allocate memory for the program's variables? The storage for the variables is not actually inside the executable ... imagine the executable is on a read-only hard disk for example, or if it's launched twice
– M.M
Nov 22 '18 at 21:17
How are you compiling the code? How are you determining the file size? Are you looking at size on disk? It might be rounding up to a cluster size (see this explanation). Are you sure you aren't accidentally looking at the same file three times? Maybe the other examples failed to compiled or compiled to another file.
– François Andrieux
Nov 22 '18 at 21:19
@M.M Mostly because I have noticed that more complex programs tend to have larger .exe files. Also (less sure but) because I am not sure how the program would know how much memory to allocate, for example, if I have 2 functions that each have a large static arrays and at runtime I select one of the functions to call randomly then one of the static arrays will never be instantiated.
– CanISleepYet
Nov 22 '18 at 21:23
@FrançoisAndrieux I am compiling on MSVC in Debug with default settings. You are correct that perhaps this is the problem. Yes I checked that the .exe was modified each time.
– CanISleepYet
Nov 22 '18 at 21:26
@JesperJuhl So you are saying that (in general and for more realistic examples) you would expect the size of the .exe to increase as more instructions and variables are added but this increase will not be linear depending on what optimizations the compiler can make?
– CanISleepYet
Nov 22 '18 at 21:27
3
3
Why doesn't it seem right to you that the OS would allocate memory for the program's variables? The storage for the variables is not actually inside the executable ... imagine the executable is on a read-only hard disk for example, or if it's launched twice
– M.M
Nov 22 '18 at 21:17
Why doesn't it seem right to you that the OS would allocate memory for the program's variables? The storage for the variables is not actually inside the executable ... imagine the executable is on a read-only hard disk for example, or if it's launched twice
– M.M
Nov 22 '18 at 21:17
How are you compiling the code? How are you determining the file size? Are you looking at size on disk? It might be rounding up to a cluster size (see this explanation). Are you sure you aren't accidentally looking at the same file three times? Maybe the other examples failed to compiled or compiled to another file.
– François Andrieux
Nov 22 '18 at 21:19
How are you compiling the code? How are you determining the file size? Are you looking at size on disk? It might be rounding up to a cluster size (see this explanation). Are you sure you aren't accidentally looking at the same file three times? Maybe the other examples failed to compiled or compiled to another file.
– François Andrieux
Nov 22 '18 at 21:19
@M.M Mostly because I have noticed that more complex programs tend to have larger .exe files. Also (less sure but) because I am not sure how the program would know how much memory to allocate, for example, if I have 2 functions that each have a large static arrays and at runtime I select one of the functions to call randomly then one of the static arrays will never be instantiated.
– CanISleepYet
Nov 22 '18 at 21:23
@M.M Mostly because I have noticed that more complex programs tend to have larger .exe files. Also (less sure but) because I am not sure how the program would know how much memory to allocate, for example, if I have 2 functions that each have a large static arrays and at runtime I select one of the functions to call randomly then one of the static arrays will never be instantiated.
– CanISleepYet
Nov 22 '18 at 21:23
@FrançoisAndrieux I am compiling on MSVC in Debug with default settings. You are correct that perhaps this is the problem. Yes I checked that the .exe was modified each time.
– CanISleepYet
Nov 22 '18 at 21:26
@FrançoisAndrieux I am compiling on MSVC in Debug with default settings. You are correct that perhaps this is the problem. Yes I checked that the .exe was modified each time.
– CanISleepYet
Nov 22 '18 at 21:26
@JesperJuhl So you are saying that (in general and for more realistic examples) you would expect the size of the .exe to increase as more instructions and variables are added but this increase will not be linear depending on what optimizations the compiler can make?
– CanISleepYet
Nov 22 '18 at 21:27
@JesperJuhl So you are saying that (in general and for more realistic examples) you would expect the size of the .exe to increase as more instructions and variables are added but this increase will not be linear depending on what optimizations the compiler can make?
– CanISleepYet
Nov 22 '18 at 21:27
|
show 4 more comments
2 Answers
2
active
oldest
votes
I compiled your program with and without the large array, dumped both section headers and compared them. This is the only difference:
Idx Name Size VMA LMA File off Algn
- 23 .bss 09896820 0000000000004020 0000000000004020 00003010 2**5
+ 23 .bss 00000008 0000000000004010 0000000000004010 00003010 2**0
As you suspected, the only size difference between the two is the size of the block of memory that the executable requests from the OS. There's may be an extra byte or two of code, but likely the code is rounded up to the nearest page anyway.
As the linked page states:
Typically only the length of the bss section, but no data, is stored in the object file. The program loader allocates memory for the bss section when it loads the program.
Thank you, this seems to give me all the key concepts that I need to google to fully understand
– CanISleepYet
Nov 24 '18 at 19:19
add a comment |
What determines the .exe file size?
It really depends on what you're making actually. But the most notable so far is the library you included in #include
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimized away and (b) see if the extra instructions would increase the number of bytes of the .exe
Did you enable debug mode? Or are you using release mode? Be careful, because in release mode, they'll optimize your code too much
.
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Your code above only contains "simple" instructions, thus, the file size wont increase.
Oh yeah, also a note, try using std::cin.get()
instead of system("PAUSE")
If you look into the assembly's perspective, all your code does is this :
allocate 4 bytes of memory at 0xRANDOM address for variable BIG_INT
allocate another 40000000 bytes of memory at 0xRANDOM+4bytes address for variable x
create variable i = 0
create goto address "loop"
output x[i] // This is also a problem, because x = null!
increment into i by one
if i is less than BIG_INT then jump to "loop"
Which is very simple to a computer. Try creating lots of functions and objects, then, you may start to see a difference.
That's for the file size in Disk, but if in Memory (RAM), it's a different story
– Sazeim Saheem
Nov 22 '18 at 23:27
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438048%2fwhy-does-the-program-size-remain-unchanged-when-more-variables-and-or-instructio%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I compiled your program with and without the large array, dumped both section headers and compared them. This is the only difference:
Idx Name Size VMA LMA File off Algn
- 23 .bss 09896820 0000000000004020 0000000000004020 00003010 2**5
+ 23 .bss 00000008 0000000000004010 0000000000004010 00003010 2**0
As you suspected, the only size difference between the two is the size of the block of memory that the executable requests from the OS. There's may be an extra byte or two of code, but likely the code is rounded up to the nearest page anyway.
As the linked page states:
Typically only the length of the bss section, but no data, is stored in the object file. The program loader allocates memory for the bss section when it loads the program.
Thank you, this seems to give me all the key concepts that I need to google to fully understand
– CanISleepYet
Nov 24 '18 at 19:19
add a comment |
I compiled your program with and without the large array, dumped both section headers and compared them. This is the only difference:
Idx Name Size VMA LMA File off Algn
- 23 .bss 09896820 0000000000004020 0000000000004020 00003010 2**5
+ 23 .bss 00000008 0000000000004010 0000000000004010 00003010 2**0
As you suspected, the only size difference between the two is the size of the block of memory that the executable requests from the OS. There's may be an extra byte or two of code, but likely the code is rounded up to the nearest page anyway.
As the linked page states:
Typically only the length of the bss section, but no data, is stored in the object file. The program loader allocates memory for the bss section when it loads the program.
Thank you, this seems to give me all the key concepts that I need to google to fully understand
– CanISleepYet
Nov 24 '18 at 19:19
add a comment |
I compiled your program with and without the large array, dumped both section headers and compared them. This is the only difference:
Idx Name Size VMA LMA File off Algn
- 23 .bss 09896820 0000000000004020 0000000000004020 00003010 2**5
+ 23 .bss 00000008 0000000000004010 0000000000004010 00003010 2**0
As you suspected, the only size difference between the two is the size of the block of memory that the executable requests from the OS. There's may be an extra byte or two of code, but likely the code is rounded up to the nearest page anyway.
As the linked page states:
Typically only the length of the bss section, but no data, is stored in the object file. The program loader allocates memory for the bss section when it loads the program.
I compiled your program with and without the large array, dumped both section headers and compared them. This is the only difference:
Idx Name Size VMA LMA File off Algn
- 23 .bss 09896820 0000000000004020 0000000000004020 00003010 2**5
+ 23 .bss 00000008 0000000000004010 0000000000004010 00003010 2**0
As you suspected, the only size difference between the two is the size of the block of memory that the executable requests from the OS. There's may be an extra byte or two of code, but likely the code is rounded up to the nearest page anyway.
As the linked page states:
Typically only the length of the bss section, but no data, is stored in the object file. The program loader allocates memory for the bss section when it loads the program.
answered Nov 22 '18 at 21:28
David SchwartzDavid Schwartz
138k14144226
138k14144226
Thank you, this seems to give me all the key concepts that I need to google to fully understand
– CanISleepYet
Nov 24 '18 at 19:19
add a comment |
Thank you, this seems to give me all the key concepts that I need to google to fully understand
– CanISleepYet
Nov 24 '18 at 19:19
Thank you, this seems to give me all the key concepts that I need to google to fully understand
– CanISleepYet
Nov 24 '18 at 19:19
Thank you, this seems to give me all the key concepts that I need to google to fully understand
– CanISleepYet
Nov 24 '18 at 19:19
add a comment |
What determines the .exe file size?
It really depends on what you're making actually. But the most notable so far is the library you included in #include
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimized away and (b) see if the extra instructions would increase the number of bytes of the .exe
Did you enable debug mode? Or are you using release mode? Be careful, because in release mode, they'll optimize your code too much
.
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Your code above only contains "simple" instructions, thus, the file size wont increase.
Oh yeah, also a note, try using std::cin.get()
instead of system("PAUSE")
If you look into the assembly's perspective, all your code does is this :
allocate 4 bytes of memory at 0xRANDOM address for variable BIG_INT
allocate another 40000000 bytes of memory at 0xRANDOM+4bytes address for variable x
create variable i = 0
create goto address "loop"
output x[i] // This is also a problem, because x = null!
increment into i by one
if i is less than BIG_INT then jump to "loop"
Which is very simple to a computer. Try creating lots of functions and objects, then, you may start to see a difference.
That's for the file size in Disk, but if in Memory (RAM), it's a different story
– Sazeim Saheem
Nov 22 '18 at 23:27
add a comment |
What determines the .exe file size?
It really depends on what you're making actually. But the most notable so far is the library you included in #include
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimized away and (b) see if the extra instructions would increase the number of bytes of the .exe
Did you enable debug mode? Or are you using release mode? Be careful, because in release mode, they'll optimize your code too much
.
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Your code above only contains "simple" instructions, thus, the file size wont increase.
Oh yeah, also a note, try using std::cin.get()
instead of system("PAUSE")
If you look into the assembly's perspective, all your code does is this :
allocate 4 bytes of memory at 0xRANDOM address for variable BIG_INT
allocate another 40000000 bytes of memory at 0xRANDOM+4bytes address for variable x
create variable i = 0
create goto address "loop"
output x[i] // This is also a problem, because x = null!
increment into i by one
if i is less than BIG_INT then jump to "loop"
Which is very simple to a computer. Try creating lots of functions and objects, then, you may start to see a difference.
That's for the file size in Disk, but if in Memory (RAM), it's a different story
– Sazeim Saheem
Nov 22 '18 at 23:27
add a comment |
What determines the .exe file size?
It really depends on what you're making actually. But the most notable so far is the library you included in #include
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimized away and (b) see if the extra instructions would increase the number of bytes of the .exe
Did you enable debug mode? Or are you using release mode? Be careful, because in release mode, they'll optimize your code too much
.
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Your code above only contains "simple" instructions, thus, the file size wont increase.
Oh yeah, also a note, try using std::cin.get()
instead of system("PAUSE")
If you look into the assembly's perspective, all your code does is this :
allocate 4 bytes of memory at 0xRANDOM address for variable BIG_INT
allocate another 40000000 bytes of memory at 0xRANDOM+4bytes address for variable x
create variable i = 0
create goto address "loop"
output x[i] // This is also a problem, because x = null!
increment into i by one
if i is less than BIG_INT then jump to "loop"
Which is very simple to a computer. Try creating lots of functions and objects, then, you may start to see a difference.
What determines the .exe file size?
It really depends on what you're making actually. But the most notable so far is the library you included in #include
Making the array non-static also had no effect. I added some code to (a) make 100% sure the variable is not being optimized away and (b) see if the extra instructions would increase the number of bytes of the .exe
Did you enable debug mode? Or are you using release mode? Be careful, because in release mode, they'll optimize your code too much
.
int main()
{
const int BIG_NUMBER = 40000000;
static int x[40000000];
for (int i = 0; i < BIG_NUMBER; ++i)
{
std::cout << x[i] << std::endl;
}
system("pause");
}
Your code above only contains "simple" instructions, thus, the file size wont increase.
Oh yeah, also a note, try using std::cin.get()
instead of system("PAUSE")
If you look into the assembly's perspective, all your code does is this :
allocate 4 bytes of memory at 0xRANDOM address for variable BIG_INT
allocate another 40000000 bytes of memory at 0xRANDOM+4bytes address for variable x
create variable i = 0
create goto address "loop"
output x[i] // This is also a problem, because x = null!
increment into i by one
if i is less than BIG_INT then jump to "loop"
Which is very simple to a computer. Try creating lots of functions and objects, then, you may start to see a difference.
answered Nov 22 '18 at 23:26
Sazeim SaheemSazeim Saheem
6411
6411
That's for the file size in Disk, but if in Memory (RAM), it's a different story
– Sazeim Saheem
Nov 22 '18 at 23:27
add a comment |
That's for the file size in Disk, but if in Memory (RAM), it's a different story
– Sazeim Saheem
Nov 22 '18 at 23:27
That's for the file size in Disk, but if in Memory (RAM), it's a different story
– Sazeim Saheem
Nov 22 '18 at 23:27
That's for the file size in Disk, but if in Memory (RAM), it's a different story
– Sazeim Saheem
Nov 22 '18 at 23:27
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53438048%2fwhy-does-the-program-size-remain-unchanged-when-more-variables-and-or-instructio%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
3
Why doesn't it seem right to you that the OS would allocate memory for the program's variables? The storage for the variables is not actually inside the executable ... imagine the executable is on a read-only hard disk for example, or if it's launched twice
– M.M
Nov 22 '18 at 21:17
How are you compiling the code? How are you determining the file size? Are you looking at size on disk? It might be rounding up to a cluster size (see this explanation). Are you sure you aren't accidentally looking at the same file three times? Maybe the other examples failed to compiled or compiled to another file.
– François Andrieux
Nov 22 '18 at 21:19
@M.M Mostly because I have noticed that more complex programs tend to have larger .exe files. Also (less sure but) because I am not sure how the program would know how much memory to allocate, for example, if I have 2 functions that each have a large static arrays and at runtime I select one of the functions to call randomly then one of the static arrays will never be instantiated.
– CanISleepYet
Nov 22 '18 at 21:23
@FrançoisAndrieux I am compiling on MSVC in Debug with default settings. You are correct that perhaps this is the problem. Yes I checked that the .exe was modified each time.
– CanISleepYet
Nov 22 '18 at 21:26
@JesperJuhl So you are saying that (in general and for more realistic examples) you would expect the size of the .exe to increase as more instructions and variables are added but this increase will not be linear depending on what optimizations the compiler can make?
– CanISleepYet
Nov 22 '18 at 21:27