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.

Reply via email to