I would only use them if they could make a difference. Delivering a whole suite of apps could make for good use, or if the app was highly modular then you could deliver packages for functionality. For a single exe? There's no point. And no UPX either. Windows does demand paging of executables. No sense using an app that's going to break it and waste RAM at the expense of a few MB of disk space.
Never. If you have a single exe, they'll result in a larger delivery, if you have multiple exe, they introduce a dependency between those exes, meaning it'll be more complicated to update just one exe down the road, so what you saved, you'll pay down the road. Also they turn off some optimizations like smart-linking, so the gains may just not materialize in some modular libraries.
Never. Large EXEs are just not a problem any more with cheap hard disks and 4 GB+ RAM in most machines.
Also to the people that use UPX or other packers: Don't. Anti-spam/antivirus programs block them as many viruses are obfuscated using packers/excryptors. My corporate firewall specifically blocks all UPX packed files.
Never. File size doesn't matters really. An application using runtime package, altough smaller exe will have a larger footprint in memory. Use run time packages only when you have to share objects between an EXE and a DLL and you cannot manage to do other way.
François Piette How do runtime packages increase memory usage? Windows isn't going to page in code that's not being used. Across multiple exes, code sharing will reduce memory usage overall.
A run time package is just a DLL. It contains ALL the components. If you create an exe, only the components you use are linked and in those components, only the methods used are linked, the others are removed by the linker.
Virtual memory works using 4KB pages. A single byte use in a page makes 4KB to be loaded.
Yes, when multiples exe are using the same packages, then only one instance is loaded in memory. Depending on what is used in the run time packages, you may start gaining memory footprint after 2, 3 or more simultaneously running applications. Usually, there is only one active application and other applications are likely to be swapped out if you have not enough memory.
Usually by these days, all computers have plenty of RAM and using run time packages is not worth the headaches introduced by the packages. Even 100MB (really huge) executable is small for a computer having 4, 8 or 16000 MB of RAM.
never...
ReplyDeletewindows 98 had a problem if size > ~9.2MB sso we used packages. Same code on NT and later w/o packages could use the 24MB exe just fine.
ReplyDeleteIf the application starts to look too big, then I use UPX.EXE.
ReplyDeleteI would only use them if they could make a difference. Delivering a whole suite of apps could make for good use, or if the app was highly modular then you could deliver packages for functionality. For a single exe? There's no point. And no UPX either. Windows does demand paging of executables. No sense using an app that's going to break it and waste RAM at the expense of a few MB of disk space.
ReplyDeleteNever. If you have a single exe, they'll result in a larger delivery, if you have multiple exe, they introduce a dependency between those exes, meaning it'll be more complicated to update just one exe down the road, so what you saved, you'll pay down the road. Also they turn off some optimizations like smart-linking, so the gains may just not materialize in some modular libraries.
ReplyDeletealso, I wouldn't use UPX either.
ReplyDeleteJust focus on your task, you can never be 100% right with a release, try to get it close.
when writing windows applications, i don't care about the size much. but on mobile platforms, for ex , ios , it's totaly different .
ReplyDeleteFor 99% applications never. For concrete very very large projects like ERPs where you have similar but not equal customers is fantastic.
ReplyDeleteI always use runtime packages (this options is set by default in all my projects). We produce a large number of executables, so economy is sufficient
ReplyDeleteNever. Large EXEs are just not a problem any more with cheap hard disks and 4 GB+ RAM in most machines.
ReplyDeleteAlso to the people that use UPX or other packers: Don't. Anti-spam/antivirus programs block them as many viruses are obfuscated using packers/excryptors. My corporate firewall specifically blocks all UPX packed files.
Never. File size doesn't matters really. An application using runtime package, altough smaller exe will have a larger footprint in memory. Use run time packages only when you have to share objects between an EXE and a DLL and you cannot manage to do other way.
ReplyDeleteFrançois Piette How do runtime packages increase memory usage? Windows isn't going to page in code that's not being used. Across multiple exes, code sharing will reduce memory usage overall.
ReplyDeleteA run time package is just a DLL. It contains ALL the components. If you create an exe, only the components you use are linked and in those components, only the methods used are linked, the others are removed by the linker.
ReplyDeleteVirtual memory works using 4KB pages. A single byte use in a page makes 4KB to be loaded.
Yes, when multiples exe are using the same packages, then only one instance is loaded in memory. Depending on what is used in the run time packages, you may start gaining memory footprint after 2, 3 or more simultaneously running applications. Usually, there is only one active application and other applications are likely to be swapped out if you have not enough memory.
Usually by these days, all computers have plenty of RAM and using run time packages is not worth the headaches introduced by the packages. Even 100MB (really huge) executable is small for a computer having 4, 8 or 16000 MB of RAM.