Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

Unit tests in IE11 get progressively slower with angular-bootstrap >=1.1.0 #5548

Closed
mikedaly opened this issue Feb 27, 2016 · 13 comments
Closed
Milestone

Comments

@mikedaly
Copy link

We have a fairly large angular app that utilizes ui-bootstrap. We also have a fairly extensive set of unit tests (~1900) that exercise as much of the system as we can in isolation. We run our unit tests using karma and jasmine against the latest version of Chrome and IE11.

During a recent upgrade from ui-bootstrap 0.14.3 to 1.2.0, I discovered that in IE11 each test in a run gets subsequently slower. Eventually, the tests slow down to the point that IE11 stops responding, and the test run fails. There's no one test that starts the sequence; each one just takes a little longer. At about 800ms for a single test, the run fails. Unit tests in Chrome behave the same through all versions.

I walked backwards through ui-bootstrap versions and discovered that the behavior was introduced in 1.1.0; 1.0.3 and all previous versions do not have this problem, and all subsequent versions do, including the latest (1.2.0).

I'll see if I can put together a set of simple unit tests that show the problem. It has to be a series of tests, though; running a single test works fine, and even running a small number of tests you might not notice the change.

Angular: 1.5.0
UIBS: >=1.1.0
Bootstrap: 3.3.6 (via bootstrap-sass)

@icfantv
Copy link
Contributor

icfantv commented Feb 27, 2016

Closing as duplicate of #5496.

Please extend us the courtesy of reading our project documentation and searching existing issues filed (both open and closed) before opening a new issue.

@icfantv icfantv closed this as completed Feb 27, 2016
@mikedaly
Copy link
Author

I do not believe that this is a duplicate of the linked issue (which I did find before posting). As evidence I present the following:

  • The bug I reported occurs in versions 1.1.0 and greater. It does NOT occur in 1.0.3 or earlier. (The linked bug was identified as being introduced in 1.0.2)
  • The bug I reported only occurs in IE. It does not affect Chrome. (I have not yet tested other browsers.)
  • The bug I reported isn't just a small performance issue that adds 1-2 seconds. Each spec in our suite takes longer than the previous spec, so eventually each spec is taking 800ms+ and the karma timeout kills the whole run. The entire test suite run takes 45 seconds in Chrome and 9 minutes in IE before it fails. Using v1.0.3 it takes about the same amount of time in both browsers.

This bug prevents us from running our test suite in IE at all.

I have not looked at the commits between those two versions (1.0.3 and 1.1.0) when the bug was introduced. But I suspect that there is something added to the DOM that isn't being removed, thus accumulating over long test runs since the DOM is not recreated between each spec. I surmise that whatever is affecting our tests would also (over time) affect a production system.

@wesleycho
Copy link
Contributor

Sounds like a potential memory leak - what components are you using?

@wesleycho wesleycho reopened this Feb 27, 2016
@icfantv
Copy link
Contributor

icfantv commented Feb 27, 2016

@mikedaly, thanks for the additional details.

@mikedaly
Copy link
Author

We are using the following components:

  • Buttons
  • Collapse
  • Dropdown
  • Modal
  • Progressbar
  • Tabs
  • Tooltip

I'll see if I can reproduce the slowdown with an isolated set of tests.

@pusherman
Copy link

I am having the same problem and for me the problem presents itself in when running Phantom JS as well.

I have about 375 tests and they typically ran between 15-16 seconds. When upgrading to >=1.1.0 I started seeing the test times increase by about 2x and then after the 2.0.0 release they time went up by about 3.5x.

After a bit of debugging today it seems as it all stems from the run block the injects the CSS in to the head. So the leak is present only when you include the ui.bootstrap module (does not require you loading any directive or service).

When the run blocks created here are omitted the run times drop back down to normal.

@wesleycho
Copy link
Contributor

Hm, that would make sense - I think we can optimize around here by creating a flag like angular.$$bootstrapCss and toggle that true inside that block & not execute the block if it is true.

PRs welcome

@wesleycho wesleycho added this to the 1.2.2 milestone Feb 29, 2016
@pusherman
Copy link

@wesleycho I may have time to work on a PR this evening but just so I understand, when would it need to be true and when would the flag need to be false?

@wesleycho
Copy link
Contributor

Basically just needs !angular.$$csp().noInlineStyle && ... to be changed to !angular.$$csp().noInlineStyle && !angular.$$uibCss && ... && angular.$$uibCss = true;

@mikedaly
Copy link
Author

mikedaly commented Mar 1, 2016

Great! I'll test out the tip to make sure it addresses what I saw.

@wesleycho wesleycho removed the PRs plz! label Mar 1, 2016
@wesleycho
Copy link
Contributor

1.2.2 is released this morning, so try it out, should fix this issue.

@pusherman
Copy link

@wesleycho just verified it is working for me now. Thanks!

@mikedaly
Copy link
Author

mikedaly commented Mar 3, 2016

Verified on my system as well. Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants