[macports-ports] 03/03: compiler_blacklist_versions: performance fix

[Ryan Schmidt]

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.