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.
Please include the version of Safari / WebKit you are using. Does this reproduce on the latest Safari Technology Preview?
Also if this app is running somewhere already, that would help us more quickly reproduce the bug.
<rdar://problem/26500039>
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)
(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.
I'll take a look tomorrow.
I was able to reproduce the bug in both Safari Technology Preview and WebKit Nightly. Investigating.
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.
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.
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
(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.
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.
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.)
FYI... this issue still exists in Tech Preview 7
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.
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.
(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.
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.
(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.