On Tuesday January 26 2016 08:55:20 Ryan Schmidt wrote:
>https://trac.macports.org/ticket/36560
Yeah, that was the one.
>There were performance concerns earlier in the discussion but I'm not sure if
>the latest version of the patch attached there resolves them.
Activating hfsCompression is still noticeably slower, and that's inevitable.
The cost can be reduced by using an accelerated zlib, but that's a delicate
issue on here that I'm not going to reignite. That said, I do use the
CloudFlare patches locally, and find that the cost is perfectly acceptable once
you take the disk savings into account. That's using a big spinning disk
though, so the cycles lost compressing data are compensated partly by less
cycles writing the data to disk.
In any case, the performance difference becomes something of an issue only on
(very) large ports like Qt, where the savings are the most important. I don't
de/reactivate (big) ports often enough for this to be an issue.
> Not really thrilled by the inline hex file and shelling out to run a
Isn't that simply a test to see if the bsdtar command found "does the trick"?
> command pipeline before every extract either
I think the system bsdtar doesn't support this on all OS X versions that do
support hfs compression.
I've never looked in detail at how activation works without this patch; does it
always use a temporary folder in ${prefix}/var/macports/software/${subport}
from which items are then moved into place? If so, the easiest approach to
making this optional would be to run a version of afsctool on the extraction
folder. Afsctool being apparent abandonware I've developed it further, letting
it process files in parallel. Combined with an accelerated zlib that makes fast
enough that even a post-build compression of Qt's build.dir is insignificant
w.r.t. to build time (for very appreciable savings).
R.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
