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

perf(autolinking)!: prioritise files with *Package.java|*Package.kt in getPackageClassName #2384

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

szymonrybczak
Copy link
Collaborator

Summary:

This Pull Request changes schema that looks for files to check to find class name, after my tests in various application the match results were included almost in every library in files with Package at the end. But our previous logic was going through every file in library with .kt and .java extension until it found file with implements ReactPackage, some libraries can have 100+ files and we were reading them until we matched relevant Regex schema 😅

I also added a fallback which checks files with *.kt and *.java extensions if it couldn't find implements ReactPackage in file with *Package at the end, which ensures us that we don't introduce any breaking change. The output of config command stays the same.

Performance improvement

I did a test in Expensify app, which is an open-source app with 50 libraries containing native code. Before my changes, we were reading 490 files to find the class name. Right now, we only check 79 (still there's a room for improvements).

Before After
Files read 490 79
Time ~7.85s ~1.15s

Test Plan:

  1. Clone the repository and do all the required steps from the Contributing guide
  2. Run this command:
node /path/to/react-native-cli/packages/cli/build/bin.js config

The dependencies field should be the same as before.

Checklist

  • Documentation is up to date to reflect these changes.
  • Follows commit message convention described in CONTRIBUTING.md


// @ts-ignore
return packages.length ? packages[0][1] : null;
}

function getClassNameMatches(files: string[], folder: string) {
return files
.map((filePath) => fs.readFileSync(path.join(folder, filePath), 'utf8'))
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if streaming is faster than reading the whole file every time: https://tangledeveloper.medium.com/how-to-read-file-line-by-line-efficiently-in-node-js-8125fe5bd185

Copy link
Member

Choose a reason for hiding this comment

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

worth to measure definitely, these declarations are usually somewhere at the top of the file so it hints some potential

Copy link
Contributor

Choose a reason for hiding this comment

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

Replacing glob.sync above with glob.stream might also be worth looking into, but making everything async might turn this into a very big PR 😛

.map(matchClassName)
.filter((match) => match);
if (!packages.length) {
files = getMainActivityFiles(folder, false);
Copy link
Member

Choose a reason for hiding this comment

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

maybe there's scope to exclude previously matched files from this list not to read same files twice

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

nice! good catch

Copy link
Member

@cortinico cortinico left a comment

Choose a reason for hiding this comment

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

Great improvement 👍 All good on my end but wait for another CLI reviews before merging this (also because I believe this is not E2E tested)

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.

None yet

5 participants