It is currently Tue Dec 12, 2017 2:04 am

All times are UTC - 8 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: GifResizer and APP size definition
PostPosted: Fri Mar 24, 2017 11:25 am 
Offline

Joined: Wed Jun 26, 2013 2:09 am
Posts: 412
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...;-)


Top
 Profile  
 
 Post subject: Re: GifResizer and APP size definition
PostPosted: Sat Mar 25, 2017 4:50 am 
Offline
User avatar

Joined: Mon Dec 07, 2009 7:09 am
Posts: 3886
Location: Sol3
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. ;)


Top
 Profile  
 
 Post subject: Re: GifResizer and APP size definition
PostPosted: Sat Mar 25, 2017 5:28 pm 
Offline
User avatar

Joined: Wed Apr 11, 2007 8:06 pm
Posts: 7411
Location: US, Texas
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.

_________________
Supporting Net Neutrality - BattleForTheNet | Why this matters | More from EFF.org


Last edited by webfork on Sat Mar 25, 2017 5:39 pm, edited 2 times in total.
(hopefully better reasoning)


Top
 Profile  
 
 Post subject: Re: GifResizer and APP size definition
PostPosted: Sun Mar 26, 2017 11:53 am 
Offline

Joined: Wed Jun 26, 2013 2:09 am
Posts: 412
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...?


Top
 Profile  
 
 Post subject: Re: GifResizer and APP size definition
PostPosted: Sun Mar 26, 2017 11:58 am 
Offline

Joined: Wed Jun 26, 2013 2:09 am
Posts: 412
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...;-)


Top
 Profile  
 
 Post subject: Re: GifResizer and APP size definition
PostPosted: Mon Mar 27, 2017 3:47 am 
Offline

Joined: Wed Jun 26, 2013 2:09 am
Posts: 412
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.... :roll:


Last edited by __philippe on Mon Mar 27, 2017 5:13 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: GifResizer and APP size definition
PostPosted: Mon Mar 27, 2017 4:44 am 
Offline
User avatar

Joined: Mon Dec 07, 2009 7:09 am
Posts: 3886
Location: Sol3
__philippe wrote:
Case in point: PhotoScape v3.4...

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


Top
 Profile  
 
 Post subject: Re: GifResizer and APP size definition
PostPosted: Fri Mar 31, 2017 7:06 am 
Offline

Joined: Wed Jun 26, 2013 2:09 am
Posts: 412
TPFC-app-Archive-size-calculation redux :

It finally dawned on me... Image

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Protected by Anti-Spam ACP Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group