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

experimentalSourceRewriting performance bottleneck #29438

Closed
JoostK opened this issue Apr 29, 2024 · 3 comments
Closed

experimentalSourceRewriting performance bottleneck #29438

JoostK opened this issue Apr 29, 2024 · 3 comments
Labels
type: duplicate This issue or pull request already exists

Comments

@JoostK
Copy link
Contributor

JoostK commented Apr 29, 2024

Current behavior

I'm observing a ~350x (not percentage!) performance overhead when enabling experimentalSourceRewriting on an entrypoint containing ElkJS. That entrypoint file is large, especially because of its source mapping segment.

This causes the loading time of this file to go from ~300ms to ~110s, causing tests to fail due to timeouts. This wasn't immediately clear, as it takes so enormously long to load.

Desired behavior

Even with such large files, experimentalSourceRewriting shouldn't cause that much overhead. I suppose it doesn't handle the source mapping line particularly well, but there should be avenues to avoid this performance cliff.

Test code to reproduce

Here's the file for which loading takes a 350x performance hit.
elkjs-entrypoint.zip

Cypress Version

13.7.1

Node version

20.12.0

Operating System

Windows 10 22H2 (19045.4170)

Debug Logs

No response

Other

I suspect it will be easiest to excercise the source rewriter with the attached JS file in a unit test to reproduce. Happy to provide additional defails if needed. I've omitted further debug logging for now but I can reproduce in that mode and share if desired.

@JoostK
Copy link
Contributor Author

JoostK commented Apr 30, 2024

Various ideas that may help:

  1. Perform a fast path to bail early if the replacement texts don't exits in the source text at all. This does require duplicate knowledge of things to rewrite, so may not be a desired approach.
  2. Always run the AST rewriter but recognize when no replacement had to be made, passing through the original source file and source map as is.
  3. Cache the transformation result and source map on disk, e.g. by its original content hash.

I may try to extract a cpu profile to find where the problem occurs, it may be that the regex that scans for source line comments has some catastrophic backtracking issues.

@jennifer-shehane
Copy link
Member

There is an issue for this here if you can add that information there: #7565 I'll close this as a duplicate.

@jennifer-shehane jennifer-shehane closed this as not planned Won't fix, can't repro, duplicate, stale Apr 30, 2024
@jennifer-shehane jennifer-shehane added the type: duplicate This issue or pull request already exists label Apr 30, 2024
@JoostK
Copy link
Contributor Author

JoostK commented Apr 30, 2024

Thanks @jennifer-shehane! I'll try to look at reproducing this myself over the coming days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants