Giters

aws / aws-cdk-rfcs

RFCs for the AWS CDK

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Faster builds

eladb opened this issue · comments

commented
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
commented

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 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).

commented

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

image