Bug 158117 – Running Ember.JS app with web inspector open runs very slow / beachballs

• Status: ASSIGNED
• Component: Web Inspector

[John Tsombakos]

Created attachment 279881 [details]
Ember.JS application

When running the attached Ember.JS application, with the web inspector open, Safari takes a very long time to respond, sometimes showing the beachball.

To reproduce:

Requirements -- Install node (http://nodejs.org); Install Ember.JS (http://emberjs.com); install bower (npm -g install bower); install ember-cli (http://ember-cli.com)

Extract the attached .zip file into a directory
In a Terminal window, change into the extracted directory and execute the commands:
    npm install
    bower install

Start up the application:
    ember server

In a new Safari window, navigate to the app:
    http://localhost:4200/teams

Without the Web Inspector open, clicking to navigate through the paged data, Safari responds almost instantly

Open the Web Inspector

Now, when navigating through the paged data, Safari takes a few seconds to respond, sometimes long enough to show the beachball cursor.

[Blaze Burg]

Please include the version of Safari / WebKit you are using. Does this reproduce on the latest Safari Technology Preview?

[Blaze Burg]

Also if this app is running somewhere already, that would help us more quickly reproduce the bug.

[Radar WebKit Bug Importer]

<rdar://problem/26500039>

[John Tsombakos]

This is happening in the Safari Technical Preview Beta 5 (and 4).

It is not happening in the release version of Safari (as of OS X 10.11.5)

[Blaze Burg]

(In reply to comment #4)
> This is happening in the Safari Technical Preview Beta 5 (and 4).
> 
> It is not happening in the release version of Safari (as of OS X 10.11.5)

Ok, that helps a lot! Someone will take a look.

[Nikita Vasilyev]

I'll take a look tomorrow.

[Nikita Vasilyev]

I was able to reproduce the bug in both Safari Technology Preview and WebKit Nightly. Investigating.

[Nikita Vasilyev]

Created attachment 279985 [details]
[Image] Timelines

I profiled the page using Timelines.

The stack is really deep but I didn't get stack overflow.
I don't know yet why it behaves differently when Web
Inspector is closed.

[Blaze Burg]

Created attachment 280061 [details]
Timeline recording of Inspector during lag

I was able to reproduce this just once, and I caught the following profile of the inspector itself. There is no indication that this is an Inspector bug, and since it's not reproducible or reducible, I don't see how we can make any more progress on this.

If there are better steps to reproduce, please add them to the bug.

[John Tsombakos]

Hm. Strange, as it happens every time I run this application. Very reproducible. Also happens in other Ember apps. 

Click around this forum, built with Ember with the inspector open and the same delay happens.

http://discuss.emberjs.com

[Blaze Burg]

(In reply to comment #10)
> Hm. Strange, as it happens every time I run this application. Very
> reproducible. Also happens in other Ember apps. 
> 
> Click around this forum, built with Ember with the inspector open and the
> same delay happens.
> 
> http://discuss.emberjs.com

The likely culprits are various instrumentation that the Inspector does. But because I can't reproduce this well, you need to help. Please try reproducing with:

 - Timelines disabled, breakpoints disabled
 - Timelines disabled, breakpoints enabled
 - JS / Allocation timelines disabled, breakpoints disabled
 - JS timeline disabled, breakpoint disabled
 - Allocation timeline disabled, breakpoint disabled

And add a comment as to which of these cases is applicable.

[John Tsombakos]

I've tried with breakpoints disabled, but see no difference.

As to the others, I'm not recording any timeline info, so I'm not sure how to disable JS / allocation timelines.

The only thing I did try was removing the timelines tab from the inspector, but that didn't make any difference.

[Blaze Burg]

Once in a while, vendor.js takes a really long time to load according to the network timeline. But, I don't know whether this is a synchronous load or not. (Ember also does some long-polling requests, so those are expected to have a super long duration.)

[John Tsombakos]

FYI... this issue still exists in Tech Preview 7

[Joseph Pecoraro]

Do you have the Type Profiler enabled? (Select a JavaScript Resource, and see if the [T] button is enabled in the Navigation Bar). That is known to impact performance during a Timeline recording.

[John Tsombakos]

It was turned on, as well as the Pretty Print option. I turned them both off, but it didn't make any difference. Note too, that I'm not recording any timeline info in the timeline tab.

[Joseph Pecoraro]

(In reply to comment #16)
> It was turned on, as well as the Pretty Print option. I turned them both
> off, but it didn't make any difference. Note too, that I'm not recording any
> timeline info in the timeline tab.

Can you take a sample of the Web Content Process that is hanging while it is hanging? Activity Monitor should show the CPU usage of a particular process spiking, and from there you can select the row, use the Cog, and "Sample Process". Save that to a file and attach. That would be very helpful in understanding the beachball.

Another option is to use `spindump` from the Terminal. If this is a multi-process issue that would get a few samples of all the processes that may be contributing to the issue.

[John Tsombakos]

I think I found something. I proceeded to do the test and tried to do a Sample... but when I clicked the buttons, there was no delay, even with the inspector open.

I then turned the Type Profiler back on, and the delay came back. I immediatly turned the Type Profiler off, but there was still a delay.

On a hunch, I closed the web inspector, then reopened it and they delay was gone!

So it looks like turning off the Type Profiler may not totally "turn off" until the web inspector tools pane is closed and re-opened.

[Joseph Pecoraro]

(In reply to comment #18)
> So it looks like turning off the Type Profiler may not totally "turn off"
> until the web inspector tools pane is closed and re-opened.

Okay! So, the performance issue here was the Type Profiler performance. It sounds like there are a few bugs here:

  1. Improve the performance of the Type Profiler
  2. Disabling Type Profiler should take affect immediately.
    => I think we had discussed this in the past and deferred until some point in the future. We should revisit this.
  3. Side Note: To encourage optimal Timeline Performance, we should disable Type Profiler during recording.