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

Faster builds #48

Closed
1 of 8 tasks
eladb opened this issue Dec 10, 2019 · 3 comments
Closed
1 of 8 tasks

Faster builds #48

eladb opened this issue Dec 10, 2019 · 3 comments
Labels
ops Operations status/stale The RFC did not get any significant enough progress or tracking and has become stale.

Comments

@eladb
Copy link
Contributor

eladb commented Dec 10, 2019

PR Champion
#

Description

  • Shared build cache?

Progress

  • Tracking Issue Created
  • RFC PR Created
  • Core Team Member Assigned
  • Initial Approval / Final Comment Period
  • Ready For Implementation
    • implementation issue 1
  • Resolved
@eladb eladb added the ops Operations label Dec 10, 2019
@MrArnoldPalmer MrArnoldPalmer added the status/proposed Newly proposed RFC label Jan 3, 2020
@CaerusKaru CaerusKaru mentioned this issue Jan 17, 2020
7 tasks
@rix0rrr
Copy link
Contributor

rix0rrr commented Dec 22, 2020

Some notes discovered while researching slow tests:

  • Jest hooks into the Node.js file loading mechanism (for running TS transforms and mocking and coverage), which is about doubling the time it takes to run the tests. Either switching away from Jest, or using a custom ModuleLoader (as recommended in feature: allow disabling of require-mock feature jestjs/jest#10540) might help. (Internal reference with some more research: D19316081)
  • Synthesis is rather slow. For a complicated stack we synthesize the entire tree twice, taking about 250ms. If we do multiple expect(...).toHaveResource(...) on the same Stack object, it re-synthesizes every time (rather than re-using the same template), incurring the 250ms overhead every time.

Unfortunately it's not trivial to cache this as we also have tests that look like:

// Set up stack
expect(stack).toHaveSomething(...);

// Call a method on a construct
expect(stack).not.toHaveSomething(...);

So we DO expect the stack template to change.

OTOH we also might try to invest into caching or otherwise making resolve faster. For example, we could probably cut down on the second resolution time by keeping track of the uncached lazies and mutating the object structure returned by the first resolve() call in place (saving one full recursion cycle).

@rix0rrr
Copy link
Contributor

rix0rrr commented Dec 22, 2020

Potentially lots of time spent in the token string concatentation as well:

image

@rix0rrr rix0rrr removed their assignment Apr 21, 2021
@mrgrain
Copy link
Contributor

mrgrain commented Oct 27, 2023

Marking this RFCs as stale since there has been little recent activity and it is not currently close to getting accepted as-is. We appreciate the effort that has gone into this proposal. Marking an RFCs as stale is not a one-way door. If you have made substantial changes to the proposal, please open a new issue/RFC. You might also consider raising a PR to aws/aws-cdk directly or self-publishing to Construct Hub.

@mrgrain mrgrain closed this as not planned Won't fix, can't repro, duplicate, stale Oct 27, 2023
@mrgrain mrgrain added status/stale The RFC did not get any significant enough progress or tracking and has become stale. and removed status/proposed Newly proposed RFC labels Oct 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ops Operations status/stale The RFC did not get any significant enough progress or tracking and has become stale.
Projects
None yet
Development

No branches or pull requests

4 participants