Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refs #1201: Parallelisation of calls to app signing for macOS #1216

Merged
merged 9 commits into from
May 4, 2023

Conversation

nondescryptid
Copy link
Contributor

@nondescryptid nondescryptid commented Apr 24, 2023

Changes

  • Modified ```sign_app()`` (src > briefcase > platforms > macOS > init.py) to use ThreadPoolExecutor (as suggested in Parallelise calls to app signing #1201) such that signing occurs in parallel. The default value for the max_workers param is currently used (min(32, oc.cpu_counts() + 4).
  • Modified test in test_sign_app to allow files to not be signed in a specific sequence. My assumption here is that signing things in a specific order cannot be expected with parallelisation, but note that I am very inexperienced in this regard.

This PR speeds up signing of files. I tried building the BeeWare helloworld tutorial app sequentially, and then with the parallelised implementation. The sequential signing took about 10 seconds, while the parallelised one took around 2.4s according to my stopwatch.
Screenshot 2023-04-24 at 1 05 35 PM

PR Checklist:

  • [ x ] All new features have been tested
  • [ x ] All new features have been documented
  • [ x ] I have read the CONTRIBUTING.md file
  • [ x ] I will abide by the code of conduct

Discussion needed: What parts of apps require signing to occur in a specific sequence, and if so, should parallelisation occur?

There are comments in the sign_app() function that state:

# Signs code objects in reversed lexicographic order to ensure nesting order is respected
# (objects must be signed from the inside out)

I am not sure about how strict this requirement is. If it is a strict requirement and lots of things might break because of not signing files in order, writing files sequentially may be the preferred implementation.
I tested my parallelised implementation with the BeeWare helloworld tutorial, which only uses Toga. I have not tested this on larger, more complex apps.

Fixes #1201

Copy link
Member

@freakboy3742 freakboy3742 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! I've cleaned up a couple of code style issues that were causing a problem with CI, added a test for a failure case that wasn't being caught, and made a small tweak to how progress bars and group sorting are applied - but this is really solid! Thanks for the contribution!

futures = []
progress_bar = self.input.progress_bar()
task_id = progress_bar.add_task("Signing App", total=len(names))
with progress_bar:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This creates a new progress bar for every group/folder; there should be a single progress bar that is reused.

progress_bar = self.input.progress_bar()
task_id = progress_bar.add_task("Signing App", total=len(names))
with progress_bar:
for path in sorted(names, reverse=True):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sorts the files in folders, but it doesn't guarantee the folders themselves are in reverse order.

@freakboy3742 freakboy3742 marked this pull request as ready for review May 4, 2023 04:08
@freakboy3742 freakboy3742 merged commit ca73427 into beeware:main May 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Parallelise calls to app signing
2 participants