[108385] trunk/dports/gis/gdal/Portfile

Landon J Fuller landonf at macports.org
Tue Jul 30 08:13:57 PDT 2013

On Jul 30, 2013, at 8:59 AM, Vincent Habchi <vince at macports.org> wrote:

> Hi!
>> I'm concerned that the net performance gain here is going to be far outweighed by the maintenance costs and user complexity. Without actually measuring the gains, there's no guarantee that these changes will actually improve performance, and in moving away from the optimization flags et al selected by the original developers, could very possibly trigger bugs in code generation output (e.g., compiler bugs, especially with bleeding-edge clang), or reveal bugs in the project that aren't apparent at lower optimization levels.
> Well, clang-3.3 is, in principle, well known and (almost) bug free. It’s a full release version, not a bleeding edge compiler anymore…

Higher optimization levels (and in some cases, normal optimization levels) often trigger buggy code generation, *especially* in a compiler as young as clang.

> as for bugs in the project… well… they will have to be unearthed sooner or later anyhow.

Unfortunately having these kinds of bugs unearthed by end-users via unusual compiler and optimization selections is unlikely to be particularly useful to the project in question, and will be costly to users.

> Remember that the perf variant is going to be optional anyhow, so we could easily restrict its use to the most advanced users.

As a developer, I think it's more conservative to not provide a potentially failing option except in cases where it's demonstrated through profiling to actually provide a significant performance advantage. It's quite possible that it could just as well introduce performance regressions, rather than actual improvements.


More information about the macports-dev mailing list