> On 16 Jul 2018, at 1:00 am, Perry E. Metzger <[email protected]> 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 <[email protected]>
> wrote:
>> On Sun, 15 Jul 2018 at 13:30, Perry E. Metzger
>> <[email protected]> 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 [email protected]
