C-Command Software Forum

DropDMG 3.2.8 max CPU

DropDMG 3.2.8, OSX 10.10.5.

created a folder to hold the new iMove 10.1.0. dropped the folder on dropDMG to create an OSX 10.4 dmg. the cpu pegged at 700% for 10 minutes or so.

Please fix.

What are you expecting to happen instead, and why? If other apps don’t need it, it is correct for the OS to use most of the CPU for the disk imaging operation.

Bzip2 compression is very processor intensive. iMovie is probably made up of files that are already internally compressed, so it might not be worth the minimal space savings that bzip2 would give you over a much faster format such as LZFSE or zlib.

Thank you for the link. Probably what I want is the 10.2 dmg. I used the 10.4 format because that was the definition preset that I had.

I’m really used to dropping a folder on disk utility and having it create a compressed dmg. simple, straight-forward. I’ve used that feature forever. in the last 2 OS’es (10.9 & 10.10), disk utility has to be open before doing the drop. it looks like in OSX 10.11, the feature itself might be gone. I have to check it more carefully to see. That’s why I’m experimenting with your program as a substitute.

I never recall disk utility consuming all the resources. My fans were going to beat the band. When I hear them, I look in activity monitor to see who is the bad boy. i see a program consuming more than 100% cpu, I consider that to be a signal of a potential error or problem. I’m sure you know more than I do about this, but your answer feels wrong to me. 7 cores? It’s not like I’m doing rendering.

Following your remarks, I did the same dmg generation with the 10.2 setting. this was much more reasonable, faster, and never pegged the CPUs. the 10.2 result was 2.07 GB; the 10.4 result was 2.04 GB. the space savings of 10.4 are definitely not worth it for me.

Thank you.

Actually, data compression is historically a task that is just as CPU intensive as rendering, in that the speed is limited by the processor (not the disk). So it’s perfectly normal for it to use the full available CPU until the job is done, and the OS is optimized to use multiple cores.

Disk Utility uses zlib level 5, which is 7–10x faster than bzip2 at compressing. See, for example, these benchmarks, and ones that (http://mjtsai.com/blog/2015/10/07/lzfse-disk-images-in-el-capitan/).

Typically compression algorithms cannot make use of parallel tasks, it is not easy to make the algorithms highly parallelizeable.
LZMA does not work in parallel either, when you see 7zip using multiple threads this is because 7zip splits the data stream into 2 different streams that each are compressed with LZMA in a separate thread, so the compression algorithm itself is not paralllel.

All standard compression algorithms have some maximum memory size, beyond which they fail to detect patterns… but for some, this number is much larger than others. For Bzip, it’s something like 900KB. For xz, it’s something like 8MB (with default settings). For 7z, it’s something like 2GB. Additionally, 7z also tries to be clever about placing files that are likely to be similar to each other next to each other in the archive, to help the compressor work better; tar doesn’t know anything about that.