PureBasic Forums - English

MachineCode wrote:What the? Don't "ROFL" me! Of course I don't think a floppy is faster! How the heck did you come up with that assumption?

I can only go by your comments. You are the one who took issue with me previously only responding to your mention of floppy instead of the other mediums. I would think it would be obvious to anybody with any experience with computers that floppies are slower than the named mediums, but evidently not everybody realizes this. If they did, they would not question why I addressed floppies and ignored the others.

MachineCode wrote:I'm saying that a compressed exe will load faster from those three mediums than the same exe in an uncompressed state.

This would be incorrect, because the exe in uncompressed state is not being loaded all at once.

Please explain to me how loading something larger than 4K is faster than loading something that is only 4K. Think very carefully before you answer, because any answer you give will be in direct contradiction to the way Win32/x86 actually works.

Thorium wrote:Thats not true. It will load the complete code section, which can be more or less than 4K.

Both of these sentences are incorrect.

Windows handles EXEs as memory mapped files. On Win32/x86 a page is 4K. It can't be larger. This is why a PE is loaded in 4K chunks, with each chunk being in its own page. Pages are only loaded as they are needed and only the code in one page can be executing at any given time. PEs aren't perfect, but they are a lot better than the old days of dealing with NEs.

Compressing an EXE provides no speed in loading. All it does loading-wise is provide bloat, adds a lot of unnecessary steps and an unnecessary waste of time and resources. The entire compressed EXE has to be loaded into memory, then uncompressed to memory or the hard drive (depending on the compressor used) and then the uncompressed EXE is loaded into memory in 4K chunks just like it would be if it was never compressed in the first place.

Of course with the new generation of kids who have been raised on Microsoft's "bloat because you can" approach to programming, they should be right at home with compressed EXEs. More memory usage for loading and slower load times for absolutely no purpose or gain! Luckily, processors are fast enough nowadays to help these developers cover up their shoddy programming and lack of ethical standards. "Bloat because you can" will be around for a long, long time...

Is it too late for me to say.... nevermind?

Zach wrote:Is it too late for me to say.... nevermind?

Too bad we can't lock our own topics.

You got the memory managment wrong. There are no memory pages in user mode. They are abstracted to the virtual memory, which is a flat address space with regions that can be way bigger than 4KB. Loading only in 4KB chunks jut isnt how it works. I worked a lot with PEs and the whole code section is allways loaded to memory. It would not make any sense to load only 4KB as there are far calls ans jumps all over the place, so you would end up loading allmost the whole code section anyway on the initial execution.

Also not the whole file has to be loaded to memory if its packed. You can exclude the ressource section in allmost any exe packer. And i dont know any that writes the decompressed file back to disc.

I'm convinced that Kuron and Blood are one and the same. Whenever one posts and gets into an argument, the other immediately steps in and backs them up. Do a search to see.

http://en.wikipedia.org/wiki/Executable_compression

I post on here backing kuron up because he's obviously more experienced and is right! Compressed exes are slower because they need to be uncompressed first.

PE format: http://msdn.microsoft.com/en-us/magazine/cc301805.aspx

Hi Blood. Your wiki link actually suggests that compressed exes are loaded faster, not slower?

A compressed executable requires less storage space in the file system, thus less time to transfer data from the file system into memory. On the other hand, it requires some time to decompress the data before execution begins. However, the speed of various storage media has not kept up with average processor speeds, so the storage is very often the bottleneck. Thus the compressed executable will load faster on most common systems. On modern desktop computers, this is rarely noticeable unless the executable is unusually big, so loading speed is not a primary reason for or against compressing an executable.

^ Right, loading a packed EXE into memory and decompressing can definitely be faster than loading the whole unpacked EXE into memory... but, the point Kuron made is that smart OSes can load smaller blocks of the unpacked EXE as needed (fastest method)... which is not possible with the packed EXE.

The true speed differences surely depend on your OS features, and what storage format (magnetic HDD, solid state, disk, flash, ...). It's probably negligible in many situations. Similarly, the difference in storage space needed is probably negligible too these days...

Thorium wrote:You got the memory managment wrong. There are no memory pages in user mode. They are abstracted to the virtual memory, which is a flat address space with regions that can be way bigger than 4KB. Loading only in 4KB chunks jut isnt how it works. I worked a lot with PEs and the whole code section is allways loaded to memory. It would not make any sense to load only 4KB as there are far calls ans jumps all over the place, so you would end up loading allmost the whole code section anyway on the initial execution.

Also not the whole file has to be loaded to memory if its packed. You can exclude the ressource section in allmost any exe packer. And i dont know any that writes the decompressed file back to disc.

the .text as any others section is loaded on demand per 4kb pages.



after sometimes, the size of the .text dropped to 16 kb because the windows kernel removed the unused code pages (surely the initialize functions which are called once at the start up and are not needed anymore)

Blood wrote:Compressed exes are slower because they need to be uncompressed first.

Nope, decompression is pretty much instant these days. I've done my own tests and can see it for myself. It's not slow like when unzipping a zip file. Much faster to run an app with compression over a network share, than without. Try it sometime.