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

jest runtime slower then non-bazel #50

Open
jbedard opened this issue Oct 20, 2022 · 5 comments
Open

jest runtime slower then non-bazel #50

jbedard opened this issue Oct 20, 2022 · 5 comments
Labels
performance Improve performance of existing features
Milestone

Comments

@jbedard
Copy link
Member

jbedard commented Oct 20, 2022

Mostly due to fs sandboxing. The readlinkSync call in nextHopSync fails and throws on most invocations causing substantial cpu usage calculating stack traces.

  1. Minimize work when calculating stack traces (reduced test time by 50%): perf: prevent preparing stack traces in fs *Sync patches rules_js#546
  2. reduce directory traversing: perf: cache fs patch fs lookups  rules_js#569
  3. avoid work when outside the sandbox, cache more: perf: fs performance improvements rules_js#1007
@gregmagolan
Copy link
Member

Measure 3 things:

  • non-bazel
  • rules_js with patches and no sandbox
  • rules_nodejs with patches and no sandbox

@gregmagolan
Copy link
Member

also measure: Is the patches overhead a one-time start-up cost or does is scale with number of test cases/specs

@jbedard
Copy link
Member Author

jbedard commented Nov 13, 2022

Overall the times with vs without the patches scale along with the number of tests, which I assume means number of files loaded. With a single test it seems about 8% slower, with 2k tests it was about 5% slower (using the best times with ~5 tries, very inaccurate but consistent enough I'll trust them).

@gregmagolan gregmagolan added this to the 1.0 milestone Jan 4, 2023
@gregmagolan gregmagolan added performance Improve performance of existing features and removed bug Something isn't working prioritized labels Feb 6, 2023
@rc-glean
Copy link

rc-glean commented Sep 1, 2023

Curious whether aspect's "mac as local dev" customers|partners|users prefer to disable sandboxing on mac per bazelbuild/bazel#8230 (comment). Confirming that we also tried --experimental_reuse_sandbox_directories and it doesn't seem to help.

Some anecdata: one of our jest test suites (Glean closed source) running under aspect takes ~6x longer to execute with the sandbox enabled vs not. 1 minute vs 6 minutes.

@tbarrella
Copy link

tbarrella commented Mar 21, 2025

Hello, I wanted to provide something to help repro two sources of slowness: https://github.com/tbarrella/jest-large

Setup slowness

I'm concerned about Jest setup time, which includes crawling that seems unoptimized for Bazel: bazel-contrib/rules_nodejs#2817 (comment)

In a large codebase, I've observed up to ~15s setup time within Bazel, compared to a ~1s setup time without Bazel (with the Jest cache). By "setup" I mean time between Jest startup and running the first test, inferred from the total time minus the "Test: _s" output

With this smaller repro, I found (on a mac)

  • ~3s setup with Bazel
  • <2s setup without Bazel, no cache
  • <1s setup without Bazel, with cache

I think in a TypeScript codebase, with JavaScript transpiled by ts_project, the crawling time is doubled due to Jest seeing both .js and .ts files

guardedReadLink

I couldn't repro it, but a possible source of long setup time seems to be deep stacks during crawling. I've seen

  • This line in handleDirent is called with something like /private/var/tmp/_bazel_tbarrella/0abc/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/app/jest_/jest.runfiles/_main/packages/a/lib/dist/a/b/c.js
  • readHopLink is then called repeatedly like this
    • /private/var/tmp/_bazel_tbarrella/0abc/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/app/jest_/jest.runfiles/_main/packages/a/lib/dist
    • /private/var/tmp/_bazel_tbarrella/0abc/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/app/jest_/jest.runfiles/_main/packages/a/lib
    • /private/var/tmp/_bazel_tbarrella/0abc/execroot/_main/bazel-out/darwin_arm64-fastbuild/bin/app/jest_/jest.runfiles/_main/packages/a
    • ...
    • /private/var/tmp
    • /private/var
    • /private
  • In between each readHopLink, this line in nextHop is being called with link = HOP_NON_LINK

File import slowness

With this repro I found test execution time to take

  • ~65s+ with Bazel
  • ~10s without Bazel

A couple suspected culprits from profiling before I made this repro:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
performance Improve performance of existing features
Projects
None yet
Development

No branches or pull requests

4 participants