-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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 spends half its time importing jest-snapshot even when it isn’t used #9554
Comments
Hey @andersk, thanks for digging into this! We do most of our importing lazily, but the modules that are evaluated inside the user's sandbox (like For some background, you can read through #3786, tl;dr being that users might mess with the globals (like That said, the speedup you're seeing is very tempting, so I think we should definitely investigate this. I wonder if making the implementations of the matchers and snapshot state lazy would help - e.g. only setting up serializers, state etc if snapshot matchers are actually called. I'll try to find some time digging into this, thank you for a short and sweet reproduction! |
Yeah, ignoring the blacklist for --- a/scripts/build.js
+++ b/scripts/build.js
@@ -143,7 +143,8 @@ function buildFile(file, silent) {
options.plugins.push(
require.resolve('./babel-plugin-jest-native-globals')
);
- } else {
+ }
+ {
options.plugins = options.plugins.map(plugin => {
if (
Array.isArray(plugin) && So now I’m curious, what exactly does this blacklist accomplish in the way of preventing test code from messing with Jest internals? It means that lots of Jest code gets loaded before the test code has a chance to run—but the loaded code still refers to globals that the test code could interfere with, so how does that help? |
This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 14 days. |
Still an issue in current |
Would you be able to look into what specifically is slow when loading |
@SimenB I got a chance to take a look at this issue and it seems that the largest source of slowdown is the babel packages inside the The screenshots below are comparing |
EDIT: No, we already try to: https://github.com/facebook/jest/blob/199f9811ae68b15879cbe18b7ef7ebd61eefcf23/packages/jest-snapshot/src/InlineSnapshots.ts#L20-L37 |
@SimenB I tried doing it this way (snippet below), since my test case was very singular in just trying to figure out what was causing the slowdown I haven't considered any other side effects from this change. Such as users messing with globals like you mentioned. var _types = () => {
const data = require('@babel/types');
_types = function () {
return data;
};
return data;
} |
This seems to still be pretty slow. But it looks like at this point, the toplevel import is okay as long as it's a [1] I'm testing with |
Refs jestjs#9554. Signed-off-by: Anders Kaseorg <andersk@mit.edu>
This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days. |
Still an issue in current --- a/scripts/buildUtils.mjs
+++ b/scripts/buildUtils.mjs
@@ -138,8 +138,7 @@ export function getPackagesWithTsConfig() {
);
}
-export const INLINE_REQUIRE_EXCLUDE_LIST =
- /packages\/expect|(jest-(circus|diff|get-type|jasmine2|matcher-utils|message-util|regex-util|snapshot))|pretty-format\//;
+export const INLINE_REQUIRE_EXCLUDE_LIST = /jest-circus/;
export const copyrightSnippet = `
/** |
This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days. |
🐛 Bug Report
I did some profiling on a directory of 500 empty tests and discovered that Jest is spending 50% of its time importing
jest-snapshot
into every test environment. Then I wrote a quick and dirty patch that ripsjest-snapshot
out ofjest-jasmine2
andjest-runtime
, and observed that it makes my tests run twice as fast (39.706s → 19.941s)!Obviously we can’t actually rip
jest-snapshot
out, but if we could import it lazily, we could get a large speedup on projects with many small test files that don’t use snapshot testing.To Reproduce
In an empty directory:
(Running tests serially with
--runInBand
gave me much more stable benchmark results.)Expected behavior
Jest should be faster! 🙂
Link to repl or repo (highly encouraged)
https://github.com/andersk/500-empty-jest-tests
envinfo
The text was updated successfully, but these errors were encountered: