Kibana 4 hangs in Firefox but not Chrome

RESOLVED DUPLICATE of bug 1054010

Status

()

RESOLVED DUPLICATE of bug 1054010
4 years ago
4 years ago

People

(Reporter: developer, Unassigned)

Tracking

({perf})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

10.28 KB, text/css
Details
12.82 KB, text/css
Details
184.75 KB, text/css
Details
241.55 KB, application/x-javascript
Details
912.60 KB, application/x-javascript
Details
65.54 KB, text/html
Details
(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141111030203

Steps to reproduce:

I'm testing out Kibana 4 beta (https://github.com/elasticsearch/kibana) and I noticed that on a specific action, Firefox will hang and throw up the script timeout dialog.  But on Chrome, it doesn't hang and is very responsive.

If you setup a Kibana 4 system (sorry, mine is not publicly accessible), the steps to reproduce are:

1 - Click on Visualize
2 - Click "From a new search" (the other options are probably fine as well)
3 - Select the index you want to use
4 - Select Pie Chart
5 - Click "Add Aggregation"
6 - Click "Split Slices"
7 - Select "Terms" in the Aggregation dropdown
8 - Hang

It appears to hang for around 30 seconds.

I've generated a profile using the Gecko profiler from https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler.  The profile is available at http://people.mozilla.org/~bgirard/cleopatra/#report=9a07f27b51220154d0fce4d0570409c352d3058a.
(Reporter)

Comment 1

4 years ago
I forgot to mention.  I'm using a brand new profile that only has the profiler installed.  So it isn't caused by addons.

Comment 3

4 years ago
(In reply to Trev from comment #0)
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0)
> Gecko/20100101 Firefox/36.0
> Build ID: 20141111030203
> 
> Steps to reproduce:
> 
> I'm testing out Kibana 4 beta (https://github.com/elasticsearch/kibana) and
> I noticed that on a specific action, Firefox will hang and throw up the
> script timeout dialog.  But on Chrome, it doesn't hang and is very
> responsive.
> 
> If you setup a Kibana 4 system (sorry, mine is not publicly accessible), the
> steps to reproduce are:
> 
> 1 - Click on Visualize
> 2 - Click "From a new search" (the other options are probably fine as well)
> 3 - Select the index you want to use
> 4 - Select Pie Chart
> 5 - Click "Add Aggregation"
> 6 - Click "Split Slices"
> 7 - Select "Terms" in the Aggregation dropdown
> 8 - Hang
> 
> It appears to hang for around 30 seconds.

I just spent 15 minutes trying to understand what kibana and elasticsearch are, despite previous experience working with lucene/faceted search, and I'm still no further in figuring out what kind of data they operate on and/or how to set them up (as in, I have both running locally now, but kibana wants a log pattern with live indices on the elasticsearch instance, and for that I presumably need data in the elasticsearch instance, and I have no idea how it should get any or what format it'd be on or where to find example data - the vimeo video they use to introduce things ( http://player.vimeo.com/video/9297470?api=1&player_id=vimeoplayer9001 ) doesn't play, and the "configuration" section on their website is unhelpful).

Can you provide a live testcase that doesn't require setting this up locally and trying to figure out how to make it "work"?

The profiles are probably going to be helpful, but I actually don't see them matching your report of the 30 second hang (or rather, there doesn't seem to be some kind of hot loop running for 30 seconds - I think the lack of painted frames might be an indication that something bad is happening, but I'm not sure how that ties into the lack of actual cpu action). Benoit, do these profiles tell you more, and/or if not, do you know someone else who could take a look?
Component: Untriaged → Untriaged
Flags: needinfo?(developer)
Flags: needinfo?(bgirard)
Keywords: perf, testcase-wanted
Product: Firefox → Core
(Reporter)

Comment 4

4 years ago
Created attachment 8521937 [details]
visualize-main.css
Flags: needinfo?(developer)
(Reporter)

Comment 5

4 years ago
Created attachment 8521938 [details]
vislib-main.css
(Reporter)

Comment 6

4 years ago
Created attachment 8521939 [details]
main.css
(Reporter)

Comment 7

4 years ago
Created attachment 8521940 [details]
jquery.js
(Reporter)

Comment 8

4 years ago
Created attachment 8521941 [details]
angular.js
(Reporter)

Comment 9

4 years ago
Created attachment 8521944 [details]
index.html
(Reporter)

Comment 10

4 years ago
I've attached a reduced test case.  It doesn't hang for 30 seconds but it does hang for a few seconds.  On Chrome, there is no hang.

To cause the hang, click on the select box that says "Date Histogram".  It is on the left side.
(Reporter)

Comment 11

4 years ago
(In reply to :Gijs Kruitbosch from comment #3)
> 
> The profiles are probably going to be helpful, but I actually don't see them
> matching your report of the 30 second hang (or rather, there doesn't seem to
> be some kind of hot loop running for 30 seconds - I think the lack of
> painted frames might be an indication that something bad is happening, but
> I'm not sure how that ties into the lack of actual cpu action). Benoit, do
> these profiles tell you more, and/or if not, do you know someone else who
> could take a look?

I think the non-e10s profile (from comment #2) shows it better.
You're hanging because you're flushing layout while executing scripts. Usually in this situation it's because you're have a loop like this:
loop:
  modify the DOM
  element.offsetWidth (flushes all modifications and reflows the page)

Your flex box elements are taking the bulk of the time.

Can you check if either the size of your DOM is reasonable or check how many time you're flushing layout?
Flags: needinfo?(bgirard)

Comment 13

4 years ago
(In reply to Benoit Girard (:BenWa) from comment #12)
> You're hanging because you're flushing layout while executing scripts.
> Usually in this situation it's because you're have a loop like this:
> loop:
>   modify the DOM
>   element.offsetWidth (flushes all modifications and reflows the page)
> 
> Your flex box elements are taking the bulk of the time.
> 
> Can you check if either the size of your DOM is reasonable or check how many
> time you're flushing layout?

If this is happening on Firefox but not Chrome (per comment #10), perhaps are they managing to optimize out the layout flush where we aren't? Is that something that we can investigate?
A better profile:
http://people.mozilla.org/~bgirard/cleopatra/#report=19bbbcb4d25dcc265866350bd44f6f69783cc0d1

I downloaded the files to my Downloads folder and ran it manually. Things doesn't seem to work but it's generally very sluggish.

needinfo?dholbert who is our Flexbox expert.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(dholbert)
The profile shows many nested layers of flexbox reflow (i.e. many nested flexboxes), so this is likely a version of bug 1082780. Marking as depending on that bug.

(Definitely useful to have another data-point showing slowness in real web content in the wild. I have some in-progress patches that should speed things up; I'll aim to circle back to them & get them checked in soon.)
Component: Untriaged → Layout
Depends on: 1082780
Flags: needinfo?(dholbert)
Version: 36 Branch → Trunk
(bug 1082780, which this depends on per comment 15, is now duped to bug 1054010. I'm marking this bug as a dupe as well -- I've verified that the testcase here is much snappier (when clicking "Date Histogram" per comment 10) after I've applied my patches for bug 1054010 & its dependencies.)
Status: NEW → RESOLVED
Last Resolved: 4 years ago
No longer depends on: 1082780
Keywords: testcase-wanted
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → DUPLICATE
Duplicate of bug: 1054010
You need to log in before you can comment on or make changes to this bug.