On Saturday January 23 2016 20:49:22 Vincent Habchi wrote: Hi,
>> I wouldn't count on it, as the really expensive operations are (hopefully) >> already handled by optimised code. > >I reckon there are parts of VLC which are written in assembly with >auto-detection to run as quickly as possible on a given model. My only gripe >(yeah, I like griping) here is that it wastes space, since you must embed all >the code for the different processors, while if you compile it you can discard >all the unnecessary code at compile time. This typically doesn't take a lot of space, and no compiler option will remove the unused code in software that was meant to support different CPUs at runtime... >I’ve a fairly new Mac (three-year old or so), so performance is no concern >during normal operation; however, watching a flick or a show while compiling >Qt5 can sometimes be jerky. My approach is to run the build on only 3 of the 4 cores I have, and with "nice -15". Building Qt5 (without QtWebengine) takes just a bit over 2h that way, as long as I don't use link-time optimisation (on a 2011 MBP with an i7). >Yeah, I should probably dig into this. 110 MiB for the standard VLC is *huge* >by my standards, especially just for watching video files. I have a MacBook >Air with the smallest SSD (128 GiB), so every megabyte spared is welcome. Of >course, your mileage may vary. Check out port:afsctool, HFS compression can make a considerable difference. >I’ll try to build the latest 3.0.0 pre-release and let you know, if you care. Why not, but I'm not planning to do anything with VLC for the time being... 'evening, R. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
