The Portable Freeware Collection Forums

Discussion carried over from some recent Gif Resizer entry Comments

on 2012-05-27 17:04 webfork wrote: Thanks for testing.
In my tests, PhotoScape (http://www.portablefreeware.com/index.php?id=1339) resizes GIFs reliably.

on 2017-03-23 21:15 philippe wrote:
@webfork
Admittedly more powerful, yet please consider :
PhotoScape does weigh in at a hefty 23MB vs GifResizer mere 627KB...

on 2017-03-24 14:06 midas wrote: @__philippe:
that wondrous tiny footprint is achieved via UPX packing -- GiF Resizer unpacked is 2,014,720 Bytes. And BTW, unpacking and repacking with a current version of UPX might decrease its size further to 586KB (KiloBytes, not Kilobits;).

@midas
One point granted: Gif Resizer is indeed packed with UPX...checked.
Second point: PhotoScape distro itself is packed with NSIS - Nullsoft Scriptable Install System,

Now, if you'll humor me...

Instead of my early crude comparison of the packages gross footprint sizes
(i.e, the total size of every uncompressed distro components, as currently defined on the main entry),
let's compare exclusively the total size of every packed PE components of our contenders, that is Gif Resiser v1.10 (GR) vs PhotoScape v3.4 (PS)

• Packed exe+dll size (Bytes)
  -----------------------------
  GR 642,560 GifResizer.exe
  
  PS
  2,090,092 PhotoScape.exe
    741,095 GdiPlus.dll
    420,512 mfc80.dll
    113,174 msvcp80.dll
    242,113 msvcr80.dll
    238,984 riched20.dll
     19,847 PSMsgHook.dll
  ----------
  3,865,817 bytes

Taking into account the sum total of each contender's PE packed components,
we still get a tidy 1/6 PE footprint ratio in favour of Gif Resizer (3,865,817 / 642,560)

CQFD/QED ...

PS
What really ought To Be or Not To Be included in an app's SIZE field definition, That is The Question...

Currently, as I understand it, an app Size displayed on the main entry is calculated as:
"the total size of every uncompressed elements included in the distro package", right ?

For the sake of meaningful comparison between different apps, we might argue about the respective merits of using Alternative™ size metrics, for instance:

• 1. "total size of every and all elements - irrespective of any compression"
  2. "total size of every PE file(s) (exe/dll) - irrespective of any compression"
  3. "total size of every PE file(s) (exe/dll) - uncompressed"
  4. "total size of every PE memory footprint"

Feasibility of assessing/calculating an actual app size from each of the above metrics:

• 1. Trivial - just look up the package external file size
  2. Easy - add up the size of each exe/dll internal package components
  3. Tricky - identify internal compressed components - decompress each candidate - add up decompressed component sizes
  4. Moderate - load PE (run) in memory - from Win TaskManager: identify Process Image name - look up memory size usage

Trusting this innocuous PS won't open a whole 'nother can of worms, of course...

I always take the unpacked size to mean the total disk cost of the extracted files, as supplied by the developer. If he chose to pack his executables with a runtime compressor, well, that's his prerogative and I'll take it as it comes.

There's two things going on here:

1. An ongoing debate on the site about providing more information vs. being succinct. For example, back when listing wrapper program links when there was really no reason to do so was decided because more information is better. That said, we don't always list available wrapper versions -- it's really up to the person owning the entry.
2. It's important to me that we give programs "advocates" as much as possible. When someone is really keyed into how great a program is, they're going to be more active in making sure that the entry is up-to-date.

For me personally, it's really an issue of who needs to know this kind of detail level? What's the use case? The assumption (I think) with uncompressed size is to know how much disk space it's going to take up. I don't think we have a significant part of our user-base that needs the additional info.

Midas wrote:I always take the unpacked size to mean the total disk cost of the extracted files, as supplied by the developer. ..

So do I,...but once in a while, an app Size "xx MB(uncompressed)" displayed for the DB entry does not quite match
the calculated total size of the distro package's internal components, hence my lingering doubt about the precise definition of "Size"...

Case in point: PhotoScape v3.4 :

• 23MB (24,146,044 bytes, rounded down ? to next MB) Displayed uncompressed DB Size
  24MB (23,728,553 bytes, rounded up to next MB) Calculated uncompressed total size of PhotoScape_3.4.exe distro components (derived from 7z)

Admittedly a small discrepancy, and yet...?

webfork wrote:For me personally...The assumption (I think) with uncompressed size is to know how much disk space it's going to take up.
I don't think we have a significant part of our user-base that needs the additional info.

Quite so...

For me, given two apps of comparable functionalities, a tighter overall disk footprint will indeed be a major discriminant;
smaller memory footprint is an added bonus. Keep them Sleek&Lean™, that's my motto...!

And by all means, please count me in as one insignificant part of the user-base who does value this additional info...

Archives components sizes - related tidbit:

Deriving PhotoScape v3.4 archive uncompressed components size ought to be simple enough...:

Just look up the archive contents from 7z List output:

• c:\>7z l photoscape_3.4.exe
  ...
  size      compressed
  --------- ----------
  6,029,603 16,108,588 1451 files

Corblimey !... uncompressed size SMALLER than compressed

The Sting : PhotoScape distro is packed with NSIS, which appears to get 7z's knickers in a statistical knot
The Fix :   Decompress PhotoScape archive myriad elements in a temporary folder

• c:\>7z x photoscape_3.4.exe -oc:.\archive
  ...

Display uncompressed components total size

• c:\>dir /S .\archive
  ...
  Total Files Listed:
  1451 File(s) 23.728.553 bytes

Phew....

__philippe wrote:Case in point: PhotoScape v3.4...

• That's the trouble with rounding -- and why I always quote Byte size.

TPFC-app-Archive-size-calculation redux :

It finally dawned on me...

An app Archive Displayed Size (ADS) is derived from the Total of its Uncompressed Components Sizes (TUCS), expressed in Bytes, calculated as :

• for small TUCS  < 1,048,576 Bytes [calc] Round(TUCS/1024)= ADS (in KB) [/calc]
• for large TUCS >= 1,048,576 Bytes [calc] Round(TUCS/1,048,576)= ADS (in MB) [/calc]

...which woud reconcile nicely some of the small discrepancies observed before.

Moral of the story:
Size your slim apps Archives by the KiloBytes, your thick ones by the MegaBytes, and run them apps merrily forever after...