[macports-ports] branch master updated: Add optimizations variant to python{27, 35, 36, 37}

Chris Jones jonesc at hep.phy.cam.ac.uk
Mon Jul 16 23:15:43 UTC 2018



> On 16 Jul 2018, at 1:00 am, Perry E. Metzger <pmetzger at macports.org> wrote:
> 
> I want to be clear about something. In theory, we could turn on
> runtime trace guided optimization for _every_ binary. Python isn't
> particularly special on this. It would also, in my opinion, be a
> horrible mistake -- the benefits are fairly small compared to the
> astonishing build times. There are people for whom this is important,
> but they're not normal users.

Its also important for the buildbots. We don’t, I suspect, have the spare resources available there to handle suddenly having all ports take an order of magnitude longer to build. This is important. For instance when a large number if builds come in at once. It currently already takes weeks to build all ports once a new OS is released. Increasing this time by an order of magnitude is probably not acceptable.

I also suspect the vast majority of ports will not gain from this by any meaningful, real world, degree. Do we, for instance, have firm numbers on what this brings to the python port ?

Chris

> 
> Perry
> 
> 
> On Sun, 15 Jul 2018 16:46:59 -0700 Eitan Adler <lists at eitanadler.com>
> wrote:
>> On Sun, 15 Jul 2018 at 13:30, Perry E. Metzger
>> <pmetzger at macports.org> wrote:
>>> It can take tens of minutes instead of a minute or two to build
>>> when you turn it on. That's quite different from the fairly slight
>>> change that normal optimization brings.  
>> 
>> Does it change the amount of time to install a binary package? For
>> most users the cost will be paid by the builders, not the users.
>> 
>>> Indeed, for some people, the
>>> extra time for the build may significantly exceed the sum of the
>>> gains they ever experience running Python over the lifetime of
>>> the binaries.  
>> 
>> And those people can turn it off.
>> 
>>> It is thus now available for users, but not the default.  
>> 
>> And this is a mistake.
> 
> 
> 
> -- 
> Perry E. Metzger        pmetzger at macports.org



More information about the macports-dev mailing list