Bug 223727 – run-minibrowser is slow

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Cameron McCormack (:heycam)]

On my machine, run-minibrowser takes 2s to do its preparatory work before the MiniBrowser binary is launched.  (I measured this just with `time run-minibrowser --help`.)

[Cameron McCormack (:heycam)]

Created attachment 424213 [details]
Patch

[Cameron McCormack (:heycam)]

Created attachment 424214 [details]
Patch

[Cameron McCormack (:heycam)]

Comment on attachment 424214 [details]
Patch

Something went wrong for non macOS builds.

[Cameron McCormack (:heycam)]

Created attachment 424217 [details]
Patch

[Sam Weinig]

Comment on attachment 424217 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=424217&action=review

> Tools/ChangeLog:19
> +        run-minibrowser needs to know what port it's running on, since that
> +        affects the build directory to look in to find the MiniBrowser binary.
> +        On macOS, webkitdirs.pm's determinePortName ends up running
> +        `xcodebuild -showsdks` to see if the current SDK has an internal
> +        variant available, but this is slow.  But we don't need to know the
> +        exact SDK name here, just the SDK platform name, to determine the
> +        port name.
> +
> +        So we shuffle some code around to avoid calling `xcodebuild -showsdks`
> +        where we can.  This reduces the time spent in run-minibrowser before
> +        MiniBrowser is launched (crudely measured with `time run-minibrowser
> +        --help`) from 2s to 0.6s on this machine.

Very nice!

Can we avoid ever calling `xcodebuild -showsdks`, and just call `xcrun --show-sdk-path` for current SDK determination instead? That should be really fast.

[Sam Weinig]

(In reply to Sam Weinig from comment #5)
> Comment on attachment 424217 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=424217&action=review
> 
> > Tools/ChangeLog:19
> > +        run-minibrowser needs to know what port it's running on, since that
> > +        affects the build directory to look in to find the MiniBrowser binary.
> > +        On macOS, webkitdirs.pm's determinePortName ends up running
> > +        `xcodebuild -showsdks` to see if the current SDK has an internal
> > +        variant available, but this is slow.  But we don't need to know the
> > +        exact SDK name here, just the SDK platform name, to determine the
> > +        port name.
> > +
> > +        So we shuffle some code around to avoid calling `xcodebuild -showsdks`
> > +        where we can.  This reduces the time spent in run-minibrowser before
> > +        MiniBrowser is launched (crudely measured with `time run-minibrowser
> > +        --help`) from 2s to 0.6s on this machine.
> 
> Very nice!
> 
> Can we avoid ever calling `xcodebuild -showsdks`, and just call `xcrun
> --show-sdk-path` for current SDK determination instead? That should be
> really fast.

Actually, ignore this, I see it want's to figure out if an internal SDK installed, and that won't do it on its own.

[Cameron McCormack (:heycam)]

I have a feeling we can do our own grovelling around the currently selected Xcode's directories to find the SDKs ourselves.  That at least contains all the SDKs on my system that show up in `xcodebuild -showsdks`.  But I'm not confident there aren't other locations that might be searched too.

[EWS]

Committed r275081: <https://commits.webkit.org/r275081>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 424217 [details].

[Radar WebKit Bug Importer]

<rdar://problem/75874999>

[Jonathan Bedard]

Reverted r275081 for reason:

Broke Apple Internal builds

Committed r275105 (235813@main): <https://commits.webkit.org/235813@main>

[Cameron McCormack (:heycam)]

Created attachment 424600 [details]
Patch

[EWS]

Committed r275196: <https://commits.webkit.org/r275196>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 424600 [details].