Bug 158117

Summary: Running Ember.JS app with web inspector open runs very slow / beachballs
Product: WebKit Reporter: John Tsombakos <johnt519>
Component: Web InspectorAssignee: Nikita Vasilyev <nvasilyev>
Status: ASSIGNED    
Severity: Normal CC: graouts, inspector-bugzilla-changes, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Mac   
OS: OS X 10.11   
URL: https://discuss.emberjs.org/
Attachments:
Description Flags
Ember.JS application
none
[Image] Timelines
none
Timeline recording of Inspector during lag none

John Tsombakos
Reported 2016-05-26 05:47:47 PDT
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.
Attachments
Ember.JS application (54.61 KB, application/zip)
2016-05-26 05:47 PDT, John Tsombakos 		no flags
Details
[Image] Timelines (414.64 KB, image/png)
2016-05-27 12:58 PDT, Nikita Vasilyev 		no flags
Details
Timeline recording of Inspector during lag (357.97 KB, image/png)
2016-05-29 09:45 PDT, Blaze Burg 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Blaze Burg
Comment 1 2016-05-26 12:40:37 PDT
Please include the version of Safari / WebKit you are using. Does this reproduce on the latest Safari Technology Preview?
Blaze Burg
Comment 2 2016-05-26 12:41:25 PDT
Also if this app is running somewhere already, that would help us more quickly reproduce the bug.
Radar WebKit Bug Importer
Comment 3 2016-05-26 12:41:41 PDT
<rdar://problem/26500039>
John Tsombakos
Comment 4 2016-05-26 12:43:24 PDT
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
Comment 5 2016-05-26 12:44:33 PDT
(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
Comment 6 2016-05-26 16:32:10 PDT
I'll take a look tomorrow.
Nikita Vasilyev
Comment 7 2016-05-27 12:44:36 PDT
I was able to reproduce the bug in both Safari Technology Preview and WebKit Nightly. Investigating.
Nikita Vasilyev
Comment 8 2016-05-27 12:58:22 PDT
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
Comment 9 2016-05-29 09:45:58 PDT
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
Comment 10 2016-05-30 07:15:15 PDT
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
Comment 11 2016-05-30 13:59:20 PDT
(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
Comment 12 2016-05-30 17:07:22 PDT
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
Comment 13 2016-05-31 10:12:45 PDT
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
Comment 14 2016-06-22 11:03:43 PDT
FYI... this issue still exists in Tech Preview 7
Joseph Pecoraro
Comment 15 2016-06-22 12:01:19 PDT
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
Comment 16 2016-06-22 12:07:05 PDT
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
Comment 17 2016-06-22 12:21:56 PDT
(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
Comment 18 2016-06-22 12:37:22 PDT
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
Comment 19 2016-06-22 13:00:16 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.