Cynthia Tang [:cynthiatang] Reporter
	Description • 8 years ago

# Test Case	
STR
1. Launch the browser with blank page
2. Open the google doc with 1 page (UTF-8) content (https://goo.gl/QgcVcP)
3. close the browser

# Browsers
Firefox version: Nightly 50.0a1 (2016/06/28)
Chrome version: 50.0.2661.75

# Result
Browser | Run time (median value) 
Firefox | 10,288.89 ms
Chrome  |  8,188.89 ms

# Video
https://www.youtube.com/watch?v=RIYaZHq6U64

# Profiler
https://cleopatra.io/#report=07e499a626cf296e5ffd4280a08e3b84d95cc9e3

# Test Script:
https://github.com/Mozilla-TWQA/Hasal/blob/master/tests/test_firefox_gdoc_read_utf8_txt_1.sikuli/test_firefox_gdoc_read_utf8_txt_1.py

# Hardware
OS: Ubuntu 14.04 LTS 64-bit
CPU: i7-3770 3.4GMhz
Memory: 16GB Ram
Hard Drive: 1TB SATA HDD
Graphics: GK107 [GeForce GT 640]/ GF108 [GeForce GT 440/630]

	Andrew Overholt [:overholt]
	Comment 1 • 8 years ago

Jonathan knows about text stuff.

	Jonathan Kew [:jfkthame]
	Comment 2 • 8 years ago

It's not obvious to me that there's a lot of "text stuff" involved here... but then, maybe I don't know how to find it in the profiler. Can you give some step-by-step guidance as to how to drill into the given profile and see text stuff where we're spending too much time?

	Andrew Overholt [:overholt]
	Comment 3 • 8 years ago

I'm sorry I was just assuming it was text/layout-related due to the content.

Is it worth running the same (or I guess similar since that's probably not strictly possible) test with other languages or English text to compare? Cynthia, is that possible?

	Jonathan Kew [:jfkthame]
	Comment 4 • 8 years ago

Yes, it'd be interesting to know whether the performance (or the perf difference from Chrome) is affected by the kind of text in the document -- e.g. Chinese vs an Indic script like Hindi vs simple English text.

	Cynthia Tang [:cynthiatang] Reporter
	Comment 5 • 8 years ago

Hi Andrew,
The test result for reading a google document (English characters):

           Median value (ms)     Average value (ms)     Standard Deviation (ms) 
Firefox |     18,072.22              17,893.50                      519.46
Chrome  |     17,394.44		     17,409.44			    114.79	
Diff.   |        677.78 (3.90%)

# Video
https://www.youtube.com/watch?v=z6eV-zjrxd8

# Test data
https://goo.gl/itZnFM

# Browsers
Firefox version: Nightly 50.0a1
Chrome version: 50.0.2661.75

	Andrew Overholt [:overholt]
	Comment 6 • 8 years ago

Does that mean it's slower for English text (by 8-9 ms (or is it actually 18 *seconds*?) for both Firefox and Chrome)? Am I comparing comment 5 and comment 0 correctly?

	Jonathan Kew [:jfkthame]
	Comment 7 • 8 years ago

Looking at the documents concerned (to the extent that they're visible in the videos), they're not really comparable... the English document has several long paragraphs of small text, which will require lots of line-breaking, while the Chinese one has a lot of single-line paras and only a little bit of line-breaking needed. That might make the English somewhat more expensive to lay out.

Nevertheless, I'm surprised at such a big difference, assuming both comment 0 and comment 5 tests were run on the same system.

AFAICT from the video, it's not primarily the text content that's taking time; watching the Firefox window in https://www.youtube.com/watch?v=z6eV-zjrxd8, the text of the document appears quite early (though it's still lagging behind Chrome). But other parts of the Google Docs UI take considerably longer to appear.

I wonder if there are other factors that affect it more than the content of the document -- e.g., whether the browser is currently signed in to a Google account or not. Is it possible there's some inconsistency between the tests on issues like this?

	Cynthia Tang [:cynthiatang] Reporter
	Comment 8 • 8 years ago

Hi Shako,
Could you please answer Andrew's question. Thanks!

The attachment is the Jason file for testing "test_chrome_gdoc_read_basic_txt_1" and "test_firefox_gdoc_read_basic_txt_1". The running time is more than 17 second. But the video length

Original Video:
Chrome  
https://drive.google.com/file/d/0BwkEhia_D6l_TUlRNUJ0SVA2Q0k/view?usp=sharing

Firefox 
https://drive.google.com/file/d/0BwkEhia_D6l_MmZKNUllc0tsbkk/view?usp=sharing

	Andrew Overholt [:overholt]
	Comment 9 • 8 years ago

Please also answer Jonathan's questions in comment 7, Shako. Thanks.

	Shako Ho
	Comment 10 • 8 years ago

Reply to comment 6,
Hi Andrew, 
Comparing to the result of comment 5 and comment 0, I will say for comment 0 we have significant difference (25%) between Firefox and Chrome, but in comment 5 we didn't see there is any significant difference(~4%).
In this case, we will not compare comment 0 and comment 5 in the same base, because they are testing in different machine (even all of our machines have similar spec, we still find some particular machines generate slightly difference result with others. we are doing the test to eliminate the difference between machines). So basically, we expected that we focus on the "difference between different browser at same round" rather than the actual running time, the running time could be slightly affected by network, machine, etc.

Reply to Comment 7,
Hi Jonathan,
You are right about Google Docs UI, according to our testing result, we actually take longer than Chrome to present the UI editor parts. 
And for the difference between comment 0 and comment 5, we all sign-in to the google account on all our tests, the scripts and contents are all the same. The only different thing is machine.
For comment 0, we ran the test on 3 different machine and get the median value of them.
For comment 5, we only pick 1 machine to ran the test and the the median value of them.
And we are trying to eliminate the difference between machine, sorry for causing the confusion. Just I said before, we should focus on the comparing difference between browser not actual running time. The comparing difference on different environment should not have huge difference, but the running time on different environment could have huge difference.

	Andrew Overholt [:overholt]
	Comment 11 • 8 years ago

(In reply to Shako Ho from comment #10)
> So basically, we expected that we focus on the
> "difference between different browser at same round" rather than the actual
> running time, the running time could be slightly affected by network,
> machine, etc.

I agree. Thanks for clarifying.

	Bobby Chien
	Comment 12 • 8 years ago

This case is same test case with bug 1269698. let's dig more in #1269698 and come back this.

	Nicolas B. Pierron [:nbp]
	Comment 14 • 6 years ago

Nobody looked into these bugs for a while, moving to P2 and waiting for [qf] re-evaluation before moving back to P1.

	Nicolas B. Pierron [:nbp]
	Comment 15 • 6 years ago

Vicky, since this qualify as a qf:p1 for Firefox 64, would it be possible to have updated information about this bug?

Adding a profile to justify that this is still a JS issue and a bit of documentation to explain how to reproduce this issue would be great.

	Kannan Vijayan [:djvj]
	Comment 16 • 6 years ago

I've re-measured this as of yesterday - on Windows 10 between Nightly and Chrome canary.  We are at parity with chrome speed on this - no perceptible difference in load time (as measured ad-hoc with my watch, a handful of itmes).

I'm closing this as worksforme, but here is a quick synopsis of time spent in the code regardless:

- 3.5% on mprotect / VirtualProtect
  - 1.8% linker
  - 0.9% baseline compile
  - 0.7% IonCacheIRCompiler

- 1.2% malloc locks
- 1.2% LookupNameNoGC
- 1.2% NativeSetProp
...

I'm closing this as worksforme given the performance parity.