[MacPorts] #36560: Use hfsCompression

MacPorts noreply at macports.org
Mon Jan 26 02:41:41 PST 2015


#36560: Use hfsCompression
--------------------------+----------------------
  Reporter:  mfeiri@…     |      Owner:  mfeiri@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  base         |    Version:  2.1.99
Resolution:               |   Keywords:  haspatch
      Port:               |
--------------------------+----------------------

Comment (by rjvbertin@…):

 Replying to [comment:22 ryandesign@…]:

 > I would say it is not MacPorts' job to suggest users use a third-party
 filesystem. We should assume MacPorts is installed on Apple's default
 filesystem and improve MacPorts to optimize that experience.

 "Job" would probably be an inappropriate term. I'd say MacPorts could
 easily *play a role* in making suggestions how to optimise the experience
 to different requirements.
 NB: "optimising 'that' experience" isn't a perfectly defined concept as
 long as you don't take user requirements into account... ;)

 > I would not recommend that. Building from source is a CPU-bound
 activity; you don't want to slow down the CPU further with
 compression/decompression during that.

 Here's what I just posted on the ML:

 {{{
 As an example: the Qt 5.4.0 source tree takes up 1.7Gb normally,
 impressively down to 400Mb extracted with --hfsCompression, with a 2x
 slower extraction.

 Use performance examples using tcsh' time command:

 Without compression, 1st time
 #> time fgrep QGenericUnixServices -R qt-everywhere-opensource-src-5.4.0/
 snip

 > 3.202 user_cpu 21.238 kernel_cpu 1:49.77 total_time 22.2%CPU {0W 0X 0D
 0K 6875136M 0F 63303R 6572I 7752O 0r 0s 0k 171188w 36188c}
 Repeated immediately

 > 1.366 user_cpu 2.381 kernel_cpu 0:04.89 total_time 76.4%CPU {0W 0X 0D 0K
 6895616M 0F 67970R 1I 372O 0r 0s 0k 5272w 482c}

 With compression: 1st time
 #> time fgrep QGenericUnixServices -R qt-everywhere-opensource-src-5.4.0/

 > 1.875 user_cpu 36.627 kernel_cpu 1:54.56 total_time 33.5%CPU {0W 0X 0D
 0K 6834176M 49F 72987R 26468I 13928O 0r 0s 0k 74067w 14795c}
 Repeated immediately

 > 1.618 user_cpu 15.632 kernel_cpu 0:46.32 total_time 37.2%CPU {0W 0X 0D
 0K 6846464M 0F 71258R 25940I 5O 0r 0s 0k 48798w 7706c}

 So there is little to no performance hit when reading from disk as long as
 the system isn't CPU bound, but for some reason the file/disk cache is
 less effective.
 }}}

 Compression-on-extraction can be activated on a per-port basis by adding
 `extract.post_args-append    --hfsCompression` to the Portfile, but I
 haven't yet found out how to ensure that port:bsdtar is used, as the
 bsdtar that Apple ship with 10.9 doesn't support the argument.

 [OT]
 Grmmblmbllgrmmbl! They develop a nifty fs feature allow to save
 considerable amounts of space, and then make it almost impossible to reap
 the benefits of that. And still some are saying that that's *not* to drive
 people to buy new (storage) hardware sooner ... O:-)
 [/OT]

-- 
Ticket URL: <https://trac.macports.org/ticket/36560#comment:23>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list