Why does the program size remain unchanged when more variables and/or instructions are added?












0















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?










share|improve this question


















  • 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
















0















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?










share|improve this question


















  • 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














0












0








0








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?










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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














  • 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












2 Answers
2






active

oldest

votes


















6














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.







share|improve this answer
























  • 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



















1















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.






share|improve this answer
























  • 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











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
});


}
});














draft saved

draft discarded


















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









6














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.







share|improve this answer
























  • 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
















6














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.







share|improve this answer
























  • 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














6












6








6







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.







share|improve this answer













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.








share|improve this answer












share|improve this answer



share|improve this answer










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



















  • 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













1















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.






share|improve this answer
























  • 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
















1















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.






share|improve this answer
























  • 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














1












1








1








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.






share|improve this answer














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.







share|improve this answer












share|improve this answer



share|improve this answer










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



















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

If I really need a card on my start hand, how many mulligans make sense? [duplicate]

Alcedinidae

Can an atomic nucleus contain both particles and antiparticles? [duplicate]