M1 vs M1 Max - macOs Archive Utility

aeronatis

New member
Posts
4
Reaction score
8
Location
Istanbul/Türkiye
When I was testing M1 Mac against M1 and Intel MacBook Pro 16" (i9-9880H), I realised both M1 and M1 Pro finished compressing my 30 GB of mixed content in the exact same time. I haven't used any other compression tool yet. Does this mean macOS archive utility does not utilise more than 4 performance cores for now?
 

Cmaier

Site Champ
Staff member
Vaccinated
Site Donor
Posts
667
Reaction score
967
When I was testing M1 Mac against M1 and Intel MacBook Pro 16" (i9-9880H), I realised both M1 and M1 Pro finished compressing my 30 GB of mixed content in the exact same time. I haven't used any other compression tool yet. Does this mean macOS archive utility does not utilise more than 4 performance cores for now?

It seems to me that compression times are gated by I/O (reading/writing “disk”). The .zip algorithm is very simple and certainly takes less time than the file access.

Also, welcome!
 
OP
aeronatis

aeronatis

New member
Posts
4
Reaction score
8
Location
Istanbul/Türkiye
It seems to me that compression times are gated by I/O (reading/writing “disk”). The .zip algorithm is very simple and certainly takes less time than the file access.

Also, welcome!

Thank you so much! It's good to be here.

I thought about that as well; however, this time, this leads to a conclusion that the faster SSD does not provide any improvement over the one on the M1 Mac, at least in terms of small random read/write. Am I wrong?

I am quite obsessive when it comes to determining the root cause of the test results. Sorry if I'm being unreasonable 😅
 

Cmaier

Site Champ
Staff member
Vaccinated
Site Donor
Posts
667
Reaction score
967
Thank you so much! It's good to be here.

I thought about that as well; however, this time, this leads to a conclusion that the faster SSD does not provide any improvement over the one on the M1 Mac, at least in terms of small random read/write. Am I wrong?

I am quite obsessive when it comes to determining the root cause of the test results. Sorry if I'm being unreasonable 😅

That could be right. The increased bandwidth helps when reading or writing large files, but given the sort of thing you are testing it probably doesn’t help too much because the access times may be dominated by the ”seek” time.
 

Nycturne

Member
Posts
19
Reaction score
14
It’s also the case that file compression is a very serial task *and* I/O bound. Sort of the worst of both worlds. It’s not something that parallelizes well, especially when using older algorithms and file formats where you want to avoid file fragmentation.

EDIT: If you look in Activity Monitor, you should see that the ArchiveService caps out at ~100% CPU while compressing, confirming it is single threaded.
 
Last edited:
Top Bottom