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

slow in browser ? #135

Closed
weepy opened this issue Dec 10, 2011 · 12 comments
Closed

slow in browser ? #135

weepy opened this issue Dec 10, 2011 · 12 comments
Labels
area: browser browser-specific

Comments

@weepy
Copy link

weepy commented Dec 10, 2011

I've got the same tests running in both the browser and in node. In node they take 3ms, and in Chrome they take 700ms. All tests are synchronous and are handling some very basic logic. The Chrome profiler seems to just report that 90% of the time is spend in the "Program" so that's not much user. At first I thought it might be due to some kind of timer - but I can't see that in the codebase. Any ideas ?

@tj
Copy link
Contributor

tj commented Dec 10, 2011

yeah i found that as well today testing some things out. what takes 2s in the browser takes 7ms with node. seems odd i'll have to look into it, im sure i can adjust the dom stuff

@tj
Copy link
Contributor

tj commented Dec 10, 2011

interesting, even commenting out the dom stuff it's still kinda slow, i did a profile as well and saw nothing useful, shaved maybe 20ms off of a 2s run from removing the dom stuff

@weepy
Copy link
Author

weepy commented Dec 10, 2011

Ok - so it seems the problem is the process.nextTick using the setTimeout, which is slow. Swapping it out for setZeroTimeout (http://dbaron.org/log/20100309-faster-timeouts) made 5 times quicker (but still much slower than node).
Can process.nextTick be replaced with a job queue ?

@weepy
Copy link
Author

weepy commented Dec 10, 2011

and replacing process.nextTick with

process.nextTick = function(fn){
  fn()
};

reduced the time back down to 3ms. (though I'm sure this will mess with async tests!)

@weepy
Copy link
Author

weepy commented Dec 10, 2011

or is it there more to do with stack traces ?

@tj
Copy link
Contributor

tj commented Dec 10, 2011

we could remove those all together for the client-side, it's just nice to shorten the stack trace

@tj
Copy link
Contributor

tj commented Dec 10, 2011

haha wow yeah that does it.. jesus.. forgot that thing is so slow

@tj tj closed this as completed in b5ff18a Dec 10, 2011
@weepy
Copy link
Author

weepy commented Dec 12, 2011

hmmmm - I'm finding that having such a long stack is a _major_ slowness if you start trying to debug ... going to look into suggested setImmediate functions.

@tj
Copy link
Contributor

tj commented Dec 12, 2011

well only the small portion would really be relevant, but yeah it does produce some ugly output

@weepy
Copy link
Author

weepy commented Dec 12, 2011

I just tried it out (copy and paste from
https://github.com/NobleJS/setImmediate)

--- works a charm in Chrome at least. It's basically unusable without this
as it's so slow with the web inspector

On Mon, Dec 12, 2011 at 6:41 PM, TJ Holowaychuk <
reply@reply.github.com

wrote:

well only the small portion would really be relevant, but yeah it does
produce some ugly output


Reply to this email directly or view it on GitHub:
#135 (comment)

@weepy
Copy link
Author

weepy commented Dec 12, 2011

scratch that - it's actually slow than the setZeroTimeout solution,

On Mon, Dec 12, 2011 at 6:51 PM, Jonah Fox jonahfox@gmail.com wrote:

I just tried it out (copy and paste from
https://github.com/NobleJS/setImmediate)

--- works a charm in Chrome at least. It's basically unusable without this
as it's so slow with the web inspector

On Mon, Dec 12, 2011 at 6:41 PM, TJ Holowaychuk <
reply@reply.github.com

wrote:

well only the small portion would really be relevant, but yeah it does
produce some ugly output


Reply to this email directly or view it on GitHub:
#135 (comment)

@weepy
Copy link
Author

weepy commented Dec 12, 2011

So from my experiments I've found that setZeroTimeout (
https://gist.github.com/579895) is the most suitable. It's currently
performing about 200% longer than the version that just calls the function,
but with the advantage that the stack is kept small.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: browser browser-specific
Projects
None yet
Development

No branches or pull requests

2 participants