On Mar 11, 2018, at 11:07, Joshua Root wrote:
> Joshua Root (jmroot) pushed a commit to branch master
> in repository macports-ports.
>
>
> https://github.com/macports/macports-ports/commit/b215f4265eff84d045c20168dfc47b4f99d5c969
>
> commit b215f4265eff84d045c20168dfc47b4f99d5c969
>
> Author: Joshua Root
> AuthorDate: Mon Mar 12 02:38:36 2018 +1100
>
> compiler_blacklist_versions: performance fix
>
> Blacklisting llvm-gcc-4.2 versions is really slow when llvm-gcc-4.2
> is not available. Add a quick sanity check based on OS and Xcode
> version to skip the expensive checks.
>
> ---
> _resources/port1.0/group/compiler_blacklist_versions-1.0.tcl | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
The only steps that this should save are calling
[portconfigure::configure_get_compiler cc ${compiler}] and checking if [file
exists ${cc}]. Checking file existence should be fast, so I guess
portconfigure::configure_get_compiler is slow? Could we optimize it?
There's a comment in portconfigure.tcl that Tcl 8.4's switch doesn't support
-matchvar. Now that we bundle Tcl 8.5 we could replace those many if...elseif
statements with a switch.
Tcl 8.5 byte-compiles switch statements for faster execution when using exact
matching, and a slower implementation equivalent to a sequence of if statements
when using regexp matching. So we could have two switch statements, with the
first one testing for exact matches against most of the compilers, where we
don't need to extract an arbitrary version number from it. And a second one to
do the slower regexp matching for the less-common versioned compilers
macports-clang-*, macports-dragonegg-* and macports-gcc-*.
In that second regexp switch, we could also list the more common cases first,
so they're more likely to match. I would guess macports-clang-* is the more
common one.
If the performance problem isn't the Tcl regular expressions but the fact that,
once we've identified which compiler we want information about, it calls
[find_developer_tool] several times, could this optimization -- to return "" on
those platform versions instead of calling [find_developer_tool] -- be
implemented there instead?
Or better yet, maybe it's in [find_developer_tool] that the optimization should
go, since that's where the perhaps expensive call to the executable xcrun is
made if the program can't be found in /usr/bin.
