The MASM Forum Archive 2004 to 2012

General Forums => The Workshop => Topic started by: theunknownguy on July 05, 2010, 04:01:13 AM

Title: Alloc vs Read
Post by: theunknownguy on July 05, 2010, 04:01:13 AM
Checking on IMAGE_SECTION_HEADER we can have the SizeOfRawData and VirtualSize.
When loading the file by OS, VirtualSize should be allocated and filled with zero...
So why dont put on SizeOfRawData the VirtualSize also (the full size of the section) in this manner we wont need to allocate space, but making only file bigger...

Does this make the load process faster or alloc virtual size and filling with zeros is faster?.

Thanks.  :thumbu
Title: Re: Alloc vs Read
Post by: drizz on July 05, 2010, 01:50:03 PM
Just put "/FILEALIGN:0x1000" switch for linker to have that (visual studio default is this value).
And no I don't think it matters nowadays. Maybe if you expect your executable to be 100MB.

Hell even NGEN-ed .net executables load up in a snap of fingers.
Title: Re: Alloc vs Read
Post by: Queue on July 05, 2010, 04:07:48 PM
''Alloc virtual size and filling with zeros'' should be faster, especially as you deal with massive data sizes, since reading a bunch of 0's out of a file off a drive would be slow. In either case, memory is still allocated to be used; the source of the 0's is the difference.

Queue
Title: Re: Alloc vs Read
Post by: Tedd on July 05, 2010, 08:05:27 PM
It's for reducing the size of the exe file and saving space.
Also, loading a small file is going to be faster than loading a large one (though the difference of a few sections' padding isn't going to change much.)
But, the overhead of loading extra data is larger since it involves physical hardware, whereas filling memory is relatively fast.
Title: Re: Alloc vs Read
Post by: drizz on July 06, 2010, 03:04:25 AM
Forgot to mention that uninitialised ( .data? ) variables reside in the extra space allocated by the virtualsize (virtual-raw). And that's the main point of it.  :wink