-
Notifications
You must be signed in to change notification settings - Fork 737
test(amazonq): performance test for LSP setup. #5677
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
Conversation
|
/runIntegrationTests |
jpinkney-aws
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since cpu/system are non deterministic we should document our performance testing strategy somewhere i.g. cpu/memory are purposely set higher to catch instances where cpu usage/memory/duration explodes on a code change and then use fs calls for determinism
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably should start a subdir in testInteg, maybe testInteg/perf/ . Or perf tests could in "normal" places (testInteg/path/to/module/) but use a foo.perf.test.ts filename convention.
Problem
continuation of reliability work
Solution
tryInstallLspinsrc/amazonq/lsp/lspController.tscaptures many potentially high risk paths in a single function, such as some I/O operations, and heavy use of theadmZipdependency.Two performance tests were added, one for handling zipping and maniupulating many small files, and one with few large files. Thresholds are set very leniently to avoid flaky tests.
The "many files" test does 250 files w/ 10 bytes each. The "large files" does 10 files w/ 1000 bytes each. These values were chosen to avoid flakiness in CI.
Included in this PR is removing the use of fs-extra in
src/amazonq/lsp/lspController.ts