Unable to reproduce the issue on mac 10.11 chrome version 50.0.2661.102 and canary - did not observe too much lag on clicking the emoji picker. However a little lag(few seconds) is seen

Could you please replicate the same on a new profile where there are no apps/extensions and update the thread. You can create a new profile from chrome://settings

I was able to recreate the issue with a fresh profile with no apps/extensions. I also recorded the timeline.

Look at the two attached files. There's "fast timeline" and "slow timeline". Fast timeline is taken right after refreshing Gmail. And "slow timeline" is taken after performing the open draft reply actions about 15 times.

Notice the overall time difference in the onClick event callback goes from 250ms to almost 1s. Also notice that in the "fast timeline" "appendChild" function only takes 3.3ms and 1% of the event time. In the "slow timeline" appendChild takes 290ms and 25% of the event time.

I've also privately emailed you a video recording (it's our Gmail so has personal information in it).


And I did mention that it happened to 9 out of the 10 accounts that we tested with. If you have multiple Gmail accounts try different ones.

Deleted: fast timeline.png 370 KB

	fast timeline.png 370 KB View Download

Deleted: slow timeline.png 339 KB

	slow timeline.png 339 KB View Download

Thank you for providing more feedback. Adding requester "tkonchada@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi all!
I was also able to reproduce the issue, after refresh the delay is gone.
But I reproduced this problem not only in Gmail. Application I'm working on also has similar problem. The thing is that we have a column with list of conversations and when user clicks on one conversation it loads to the main area. Users have complained of performance a lot lately. After some time of working the rendering of the main area starts to take about 5-10 seconds (normally it should be 2s maximum). I profiled the application and noticed that DOM operations (like appendChild, replaceChild, cloneNode, insertBefore) performed very slow. For example, in normal state I can see at the timeline about 10 appendChild operations (I guess other appendChild calls aren't shown in the timeline cause the take less then 0.01ms), and when the performance is bad its number is about 400 and some calls can take several milliseconds.
So my problem looks very similar to this issue. It seems like users started to complain about this problem after they updated to 50v.

I am observing the exact same problem on the application that I work on, and it also started when Chrome 50 was released.

This is also occurring with Windows 7 starting with Chrome V50 and is still present with v51.

+tkent, could you investigate this? There's a few independent reports of M50 so this is probably something.

The reproduce step is too complex to investigate this.  Can someone make a smaller reproduction?

 Issue 614856  might be related to this.

Hi tkent, I just sent you an email with the video to show how the reproduction steps aren't that bad. You don't need to generate new draft replies each time. If you already have a bunch of threads with draft replies you just need to visit those threads and that will trigger the slow DOM operations.

Thank you for providing more feedback. Adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hmm I couldn't reproduce the issue even in the way of oismail@'s video.

Would anyone collect tracing file by following steps, and attach it to this issue please?  The file won't contain any privacy data.

1. Open "chrome://tracing/" in new tab.
2. Close all tabs other than the chrome:://tracing/ and the site you reproduce the performance issue.
3. In chrome:://tracing/, press [Record]
4. Click "Edit categories" in a dialog
5. Check "blink_gc" "blijnk.invalidataion" and "blink.style" in the right column (do not uncheck others)
6. Activate the tab of the site with performance issue.
7. If you need some operations before observing the slowness, do them. (Something like step 1-7 in the original report)
8. Switch chrome:://tracing/ tab
9. Press [Record] in the dialog
10. Switch to the tab of the site
11. Do the slow operation. (Like step 8 in the original report) Wait until the operation is done.
12. Switch to chrome://tracing/ tab
13. Press [Stop] button in the dialog
14. Press [Save] button at the top
15. Type "slow-dom" in the text field in the dialog, and press [OK] button
16. You'll have trace_slow-dom.json.gz.  Please attach it here.

Please find the trace attached.

Also I was going to do a git bisect on the Chromium project to figure out the first commit that introduced the problem. But building Chromium is a huge pain and build times are ridiculous. Please let me know if the trace gives sufficient information or if I should do the git bisect.

Deleted: trace_slow-dom.json.gz 914 KB

trace_slow-dom.json.gz 914 KB Download

Sorry, I didn't have the correct blink.style selected. Here's the new trace with the correct settings.

Deleted: trace_slow-dom (1).json.gz 869 KB

trace_slow-dom (1).json.gz 869 KB Download

Here are 2 more traces with different settings, I think the main one that shows more information is the v8.cpu_profile.hires

I took one trace when Gmail was in a good state (fast-dom-v8-hirez) right after refreshing. And I took another trace after putting Gmail into a slow state (slow-dom-v8-hirez).

It's easy for me to generate these trace files, so let me know if there are other recording settings you'd like me to try it with. Hope this is helpful.

Deleted: trace_slow-dom-v8-hirez.json.gz 1.9 MB

trace_slow-dom-v8-hirez.json.gz 1.9 MB Download

Deleted: trace_fast-dom-v8-hirez.json.gz 1.4 MB

trace_fast-dom-v8-hirez.json.gz 1.4 MB Download

Thank you for the data!
What I understand for now is V8.External consumes 1.484sec in the slow case, and 0.17sec in the fast case.

#14
> Also I was going to do a git bisect on the Chromium project to figure out the first commit that introduced the problem. 

Thank you for trying it.
If you have a Chromium checkout, you have a useful tool.

% ./tools/bisect-build.py -g 369907 -a YOUR_PLATFORM

369907 is a branch point of Google Chrome 49.  Probably you want to specify -p to keep Gmail credential.  This command downloads various revisions of Chromium, and ask you to reproduce the problem interactively.

That bisect-build tool is amazing! Here's the result:

You are probably looking for a change made after 371206 (known good), but no later than 371212 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/80858159012549fb0d3579d1c77e2ab243ec6ec3..d6193f3c2f6d043b3588290fdbfdefbc88f7a208


If there's nothing in those commits that looks suspicious then it's possible I screwed up the bisect and said one was good when it wasn't. For sure 371212 is bad. The other one I said was good that's near the lower bound is 371203. I also said 371181 was good. It's highly unlikely I marked all 3 of those revisions as good mistakenly.

Let me know if there's anything else I can do.

#18, Thank you very much!
Then Oilpan is most suspicious.

Agreed that Oilpan is the most suspicious. Please let me know in what other ways I can help out i.e. running a specific version of Chromium with extra diagnostics running while I trigger the bad behavior.

(I deleted comment 20 because I posted about Oilpan before I refreshed the page and saw your comment)

I cannot access the info for  issue 613658  (https://bugs.chromium.org/p/chromium/issues/detail?id=613658).  It tells me I don't have permission to view the requested page.

How can I track down the status for this issue since I don't have access to the issue it has been duplicated against?

 Issue 614856  has been merged into this issue.