Jump to content

HD Space taken up


Recommended Posts

Yesterday I downloaded and installed updates for Designer, Photo and Publisher.  Before beginning, I had 766 Gigs of HD space available. After installing the updates, HD space had dropped to 459 Gigs of space. Would the updates have anything to do with this dramatic 7-Gig decline in HD space?

 

 

Link to comment
Share on other sites

You mean 759GB.

Which Operating System are you using? 

Affinity apps are roughly 2.4-2.5GB unpacked and installed so 7GB is close to the figure you are seeing. On Mac's an installer will ask to replace and app or keep both.

 

iMac 27" Late 2019 Fully Loaded, iMac 27" Late 2013 both running Catalina 10.15.7 - Affinity Designer, Photo & Publisher, Adobe, Inkscape, Blender, C4D, Sketchup, Pepakura Designer + more... XP-Pen Artist-22E, - iPad Pro 12.9 B|  

Affinity Help - Affinity Desktop Tutorials - Feedback - FAQ - most asked questions

Link to comment
Share on other sites

Universal (2) binaries on MacOS are twice the size of the single architecture binaries, and they're a good way to waste disk space. Take the largest file in the APub installation: liblibpersona.dylib. It is 1GB in size. It supports two architectures: x86_64 and Apple's own arm64. Roughly half the size of this file is devoted to each platform. Congratulations! If you have an Intel chip you've just given 500MB of space disk space away to arm64, and vice versa. 

So that is why later versions of Affinity on MacOS are roughly twice the size of earlier versions, and roughly twice the size of Windows.

[xxx@xxx:12:56:20:/Applications/Affinity Publisher 1.10.app/Contents/Frameworks] (517) % lipo  -detailed_info liblibpersona.dylib
Fat header in: liblibpersona.dylib
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    capabilities 0x0
    offset 16384
    size 557917936
    align 2^14 (16384)
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    capabilities 0x0
    offset 557940736
    size 503671568
    align 2^14 (16384)

 

Link to comment
Share on other sites

And they each ship with exact copies of the SAME frameworks, roughly 2GBs each in:
Affinity {Designer|Photo|Publisher}.app/Contents/Frameworks/liblibaffinity.dylib, liblibrenderer.dylib, liblibrastertools.dylib, etc…

I miss the days of shared frameworks, and where each and every app didn't include MBs/GBs of redundant libraries and frameworks (I'm also looking at you Electron apps). With SSDs today often being fixed to the motherboard (and hence not upgradable), and being rather expensive when buying from the manufacturer (ahem, Apple - your only option) many folks often opt for smaller SSDs to save a little cash. Developers requiring GBs of precious SSD space to install multiple copies of the same frameworks and libraries feels rather presumptuous (and obnoxious) today. The App Store and the sandboxing requirement definitely didn't help.

Link to comment
Share on other sites

3 hours ago, Bryan Rieger said:

I miss the days of shared frameworks...

I do not miss how if a shared framework became damaged, or was removed by an 'app cleaner' that was not aware multiple apps shared it, then every app that shared it started acting weird. I also remember having a few problems because updating some versions of certain apps installed an updated shared framework that did not work correctly with some of the other apps it was shared with.

That said, I do wish the Affinity installers only installed what is needed for the hardware instead of for both architectures. 

Affinity Photo 1.10.5, Affinity Designer 1.10.5, Affinity Publisher 1.10.5;  2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7
Affinity Photo 
1.10.5.280 & Affinity Designer 1.10.5 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.0.2

Link to comment
Share on other sites

56 minutes ago, R C-R said:

That said, I do wish the Affinity installers only installed what is needed for the hardware instead of for both architectures.

I can understand the single "delivery package" but it seems bonkers to me that it then installs both versions. Do all universal apps do that or is this maybe an error?

Link to comment
Share on other sites

3 hours ago, R C-R said:

I do not miss how if a shared framework became damaged, or was removed by an 'app cleaner' that was not aware multiple apps shared it, then every app that shared it started acting weird. I also remember having a few problems because updating some versions of certain apps installed an updated shared framework that did not work correctly with some of the other apps it was shared with.

Yeah, Windows DLL hell was, ‘special’. NeXT and macOS did have a nice way of dealing with them via /Library/Frameworks, but it’s largely fallen out of fashion/use.

Just delivering the lib versions for the required architecture would be most welcome.

Link to comment
Share on other sites

4 hours ago, R C-R said:

That said, I do wish the Affinity installers only installed what is needed for the hardware instead of for both architectures. 

Indeed. I have all three Affinity apps installed and I suffer about 3GB of wasted disk space as a result. Not so much a problem on my iMac, but on my laptop it's significant. It is wasteful.

Link to comment
Share on other sites

4 hours ago, BofG said:

Do all universal apps do that or is this maybe an error?

That is the way universal binaries work. I don't have many apps installed on this machine, but Firefox is a universal binary. Once again, about 50% is given to each architecture:

[xxx@xxx:23:31:47:/Applications/Firefox.app/Contents/MacOS] (624) % file XUL 
XUL: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64]
XUL (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
XUL (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

[xxx@xxx:23:31:49:/Applications/Firefox.app/Contents/MacOS] (625) % lipo -detailed_info XUL 
Fat header in: XUL
fat_magic 0xcafebabe
nfat_arch 2
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    capabilities 0x0
    offset 4096
    size 139995792
    align 2^12 (4096)
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    capabilities 0x0
    offset 140001280
    size 136944144
    align 2^14 (16384)

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.