-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
10x slowdown in 0.5.8 after 0.4.0 #334
10x slowdown in 0.5.8 after 0.4.0 #334
Comments
I just tried to run AngularJS unit tests, it's almost 1600 unit tests. The times are comparable.
|
We should definitely investigate this. Speed is very important. |
Do you see this slow down in Chrome as well ? |
Very interesting. That's a good idea, thanks. I'll do some investigation and report back. |
Do your tests do a lot of console logging? |
Not intentionally, but our mvc framework (ember) often does spit out a bunch of warnings along the way. (Commence angular vs ember jokes ;) |
@bitwiseman that's a very good point, I think we introduced patching console, so every console.log() means a sending the output to the server. |
I just found this info about stdout and stderr in [http://nodejs.org/api/process.html#process_process_stdout](the nodejs documentation):
It might not be sending to the server that is the worst offender. |
I found our tests run just as fast in Chrome and Firefox between 0.4.0 and 0.5.8. Fast across the board there. The difference lies in phantomjs only. I'm running phantomjs 1.8.1. Although our tests do spit out some console.warns and console.traces, I don't believe this is the root of the cause. Before the tests run, I did the following: console.warn = function () {};
console.error = function () {};
console.trace = function () {}; That stops the chatter in the browser when running the tests. I hope that does what I think it does in phantomjs. Any ideas for profiling phantom? |
Did you null I'm not sure how to profile PhantomJS. But I still think, that this console.log thing might be the problem. You might try https://github.com/ariya/phantomjs/wiki/Network-Monitoring (capture the browser manually with your script). |
any progress with this issue? |
@ahaurw01 Any updates ? |
This is running quite slow for me as well. Here is the output from my latest: Chrome 25.0 (Mac): Executed 25 of 25 SUCCESS (5.006 secs / 0.02 secs) Only 25 tests and it is crawling at 5 seconds. At first I thought it was the preprocessor but even after disabling code coverage there is no change. This is painfully slow, anything you can do to speed it up is greatly appreciated. |
I just realized that I am using v0.8.0 if that helps. |
Are the tests you speak of for an open source project when we could pull and run them locally for debugging? That would be really helpful. Is this on windows? OSX? |
Unfortunately the tests are not open source so I can't share them. I am running OS X 10.7.5. |
Another interesting observation. When I turn on Chrome 25.0 (Mac): Executed 25 of 25 SUCCESS (0.385 secs / 0.011 secs) |
@alindsay55661 thanks, the chrome timelime helps. This means, Karma spends this time by composing context.html. Could you try different versions (of testacular as the project got just renamed so there are no older versions of karma). And see which version introduced this ? Can you try 0.4.0 first ? Can you also run it with Can you try just regular Can you also share your |
Yikes, after turning on debug it became obvious what the problem is, or at least part of the problem. On startup the resolver is going through every file in my project, including a deep list of node modules. There are no paths in
But then is lists hundreds of node modules and other files including my
Using karma's Node is now running at 100%+ cpu when using karma's The problem with using karm's Here is my
When I get some time I will take a look at past versions. |
There's nothing like html version of js files in karma, I guess these are your handlebars files or something. Remove the The fact that Karma watches even files that does not match patterns needs to be fixed, it's already on my list. Ad. watching and compiling stuff. I think you could use a Karma preprocessor for compiling handlebars on the fly. Another solution is to use grunt for that and let Testacular to watch the output (already compiled files) rather then the sources. Does it make sense ? |
Yeah makes sense, will give it a try. As far as the html files go, they are definitely not from handlebars. Are you sure these aren't from your Istanbul implementation? I would consider that part of Karma since I never installed it and it automagically works. |
Oh, yep, the istanbul, that's it! Sorry about the confusion. On Fri, Mar 29, 2013 at 9:02 AM, Alan Lindsay notifications@github.comwrote:
|
Ok the change in paths fixed the speed issue for me. If you recently renamed I had had some issues with the paths before and several posts in this forum were suggesting the use of |
Cool. Btw, no renaming, use debug.html only for debugging (it disables On Fri, Mar 29, 2013 at 9:55 AM, Alan Lindsay notifications@github.comwrote:
|
Ok, I believed we resolved @alindsay55661 's issue. @ahaurw01 did you figure out ? I'm planning on adding |
I'm not sure how much this will help but I've been getting slow down issues where i'm using the jasmine .toContain() function. E.g. Sometimes I'm searching text larger than above but normally only the innerHTML of an element (so not too much more). I figured if I was doing a search of all the text of the page that would cause an issue but not a small block. If I use chrome and clear the cache or right click reload -> empty cache and hard reload the tests run in 1.1 seconds but after a couple of runs they can be up to 40 secs and i've only got 40 tests. I'm doing directive testing so compiling directives and injecting data so I know that can make it run a little slower but there's a significant slow down, maybe it's a memory leak or something in my code. EDIT: I've just switched to grabbing the css value with jquery and that seems to have sped it up for me. EDIT 2: I've noticed if I give the chrome browser window focus the tests run in the expected time but otherwise they crawl if the window doesn't have focus (Chrome 28). |
I'm sorry I've gone dark, @vojtajina. I actually have switched to using mocha-phantomjs for my needs, which right now is strictly running a set of unit tests on a headless CI server. |
Just to follow up on @RobinHoody's comment, I am seeing huge slow-downs running a simple test suite on a tiny angular app when the tab is not focused in Chrome. When I focus the tab the tests complete almost instantly. I'm on Chrome OS X 29.0.1547.65 |
I am seeing the same thign as @mlynch the first run is when the tab is not in focus, the second is with the tab in focus Chrome 29.0.1547 (Linux): Executed 4 of 4 SUCCESS (11.998 secs / 3.89 secs) |
@mlynch @am17torres yep, that's a good point - the tab has to be "focused" (that's one of the reasons why Karma starts its own browser). If the tab is not focused, the browser does not give it CPU. Karma can't do anything about that. Guys, is there any other issue? Also the issue with watching all the files inside |
Closing this for now due to inactivity. Feel free to open a new issue with current information if this is still a problem. |
Anecdotal evidence of troublesome performance decreases in 0.5.8:
I have a suite of about 150 tests being run with the mocha adapter in phantomjs. Using 0.4.0 these tests finish within a little over 1 second. Upgrading to 0.5.8 sees a running time of around 11 seconds.
Is anyone else seeing these results?
The text was updated successfully, but these errors were encountered: