cypress: Cypress slows down drastically over long runs - restart renderer between spec files?

Hi @brian-mann , I’m just scratching the surface of Cypress but i would appreciate if any of you could help me with the following situation: 1- Within my app, once a certain button is clicked, a spinner is triggered and once it’s done a page with a modal (which has a read-only text area) and i’m trying to grab a !DOCTYPE html PUBLIC using contain (cy.get('.modal-wrapper').contains('!DOCTYPE html PUBLIC');) being .modal-wrapper a class active within that modal… So in my attempt to get to this modal i did

describe('Hitting Complete email button', function() {
  it("Completes your email", function() {

    cy.contains('Complete')
      .click()
    cy.get('.modal-wrapper').contains('!DOCTYPE html PUBLIC');
  });
});

But after clicking that button i get CypressError: Timed out retrying: Expected to find element: '.modal-wrapper', but never found it. and then i keep getting

(XHR)
POST 403 /campaign/spent-time
(XHR)
POST 403 /campaign/lock
(XHR)
POST 403 /campaign/spent-time
(XHR)
POST 403 /campaign/lock
(XHR)
POST 403 /campaign/spent-time
(XHR)
POST 403 /campaign/lock
(XHR)
POST 403 /campaign/spent-time  

But my test never gets to assert that the text I’m looking for does exist, cypress never gets to that point in my app (and it’s working ok)

Any help would be very much appreciated, apologies in advance this is my very first post and I’m not a natural speaker.

Thanks a lot

No. We definitely do not run anything from the GUI.

The GUI isn’t meant to run entire test suites. It’s meant to be used in your day to day development typically on a single test file or maybe just a few.

The GUI is not optimized for long runs, only headless is.

For instance numTestsKeptInMemory by default is 50 for headed runs. This essentially keeps every single DOM snapshot for every single command for tests up to 50 in memory. That’s why the headed browser will eventually slow down.

This configuration option is automatically set to 0 when running headlessly. There are also lots of internal optimizations because when you’re running headlessly you cannot interact with the test results. For instance, we don’t even take DOM snapshots when running headlessly.

So… all of what I said above was about headless runs. If you’re trying to use the GUI for this, it definitely won’t work and likely won’t ever work for all of these reasons.

I thought you were having problems running headlessly (?)

4 Years later and i still experience this problem…

I am still having this issue in 3.0.2. DOM snapshots appear to leave behind significant memory residue - if I set numTestsKeptInMemory to 0, I have significantly lower memory usage, though it’s worth noting that it still climbs. My memory consumption increases drastically in proportion to numTestsKeptInMemory.

My tests don’t actually slow down until my computer runs out of memory. The first time I noticed this issue, Cypress was taking over 10 GB of memory. That may have been an anomaly, because I haven’t been able to reproduce anything like that since.

I’m not convinced this is a separate issue. According to the release notes for 3.0.0, Cypress is completely refeshed for every file. I’m having this issue with a single test file that tests a single component. I believe the main reason I’m still having this issue is because the DOM structure of my application is significantly more complex than average, and it appears that the fix depends on either your application or your individual test files being fairly simple. In addition, my test is data driven, so it repeats the same set of steps for about 25 different data points.

Here are the memory results I’m getting. Each screenshot is taken directly after running my test file.

numTestsKeptInMemory set to 0:

numTestsKeptInMemory set to 1:

numTestsKeptInMemory set to 10:

I also tested putting each part of the data-driven section as its own test instead of its own .it() step. This didn’t seem to make a difference. Putting the entire data-driven test as a .it() caused significant slowdowns and somewhat higher memory usage. I would guess this to be due at least in part to the number of commands that were issued in the .it().

numTestsKeptInMemory set to 30:

---

In addition, the memory increases in the moments following each test run before settling back down to the values you see in the screenshots above. Here is where the memory peaked for the numTestsKeptInMemory: 30 test after it was finished running:

---

I am running Cypress 3.0.2 in Windows 10. All tests were performed in the Electron 59 browser.

Any response to this?

I too am getting this issue, using v1.4.1. Running all of my 30+ tests in the GUI causes a total absorption of my 16gb of memory and ultimately some random test will fail with a timeout error rather than the GUI crashing or failing. I accept that I shouldn’t be running all the tests all at once and so I’m typically developing each new test using it.only so that only test runs at a time. My problem is that even using it.only my memory consumption still increases and so that once every 30 minutes I need to close and re-open the Cypress GUI, which causes an immediate recovery of the memory. I’ve read above that large numbers of tests should be run using cypress run but this makes no difference for me and memory is still soaked up until it’s totally consumed and then swapping begins. Anyone any ideas?

@L4mPi2 Issues in our GitHub repo are reserved for potential bugs or feature requests.

We recommend questions relating to how to use Cypress be asked in our community chat. Also try searching our existing GitHub issues, reading through our documentation, or searching Stack Overflow for relevant answers.

Released in 3.0.0.

Yes it’s possible. If there were slowdowns during the same test re-run over a period of time that would be indicative of a memory leak. It would actually be very surprising to me as we have memory test regressions and we’ve done a lot of analysis to make sure there isn’t any - but its possible. Because every app is different and everyone uses different Cypress commands, there could be a weird edge case / combination that we can’t otherwise reproduce.

If it’s happening in the GUI you can actually do the profiling yourself / export it to show it happening. I’m not going to lie, it’s a lot of work and can take hours investigating just the area you think it may be happening before even understanding why, and then implementing on a fix.

When we open source Cypress this can be made much easier.

Regardless even if there is or isn’t a memory leak, some of my above suggestions will likely make their way in which will help with avoiding these problems as well.