I said that the file must have a lot of functions because the JS file generated by GWT contains a really lot of functions something like...
function aa(){...}
function ab(){...}
function ac(){...}
...
And traces looks like every function is compiled independently. This is pure speculation, but looks like this per-function compilation is destroying the whole file compilation performance.

Might be related to https://bugs.chromium.org/p/v8/issues/detail?id=4422. 

Might be related to https://bugs.chromium.org/p/v8/issues/detail?id=1902

I can repro that locally with the attached index.html.

Chrome 50 was around 50 % of the speed than Chrome 46.

Can the test please confirm and bisect?

Deleted: repro591340.zip 5.3 MB

repro591340.zip 5.3 MB Download

Mac Desktop - Chrome Version 48.0.2564.116 (64-bit)
Before: 318.09; After: 5973.10; Diff: 5655.00
Before: 20.37; After: 5536.55; Diff: 5516.180
Before: 20.04; After: 5812.32; Diff: 5792.27
Before: 20.43; After: 5150.73; Diff: 5130.30

Mac Desktop - Chromium Version 47.0.2491.0 (64-bit)
Before: 9.70; After: 5366.24; Diff: 5356.53
Before: 9.63; After: 4944.07; Diff: 4934.43
Before: 9.98; After: 646.08; Diff: 636.105
Before: 8.61; After: 702.02; Diff: 693.41

Mac Desktop - Firefox
Before: 51.01; After: 3061.16; Diff: 3010.15
Before: 10.24; After: 2774.83; Diff: 2764.59

Android - Firefox
Before: 118.94; After: 18746.79; Diff: 18627.85

Android - Chrome last
Crash

Tested the issue on Mac 10.10.5 using 48.0.2564.116, canary 51.0.2666.0 with below steps:

1.Opened index.html in chrome.
2.Clicked on network tab in dev tools.
3.Observed the speed in index.html.
4.Refreshed the page and observed the speed decreased.

Please find attached screencast and update if anything missed here in triaging the issue.

ignacio.bacamt@Could you please provide expected behavior screencast for better understanding the issue to triage it further.

Deleted: 591340.mp4 827 KB

591340.mp4 827 KB Download

Below are the data from different Channels on Mac 10.11.3 using 51.0.2669.0 canary, Stable 49.0.2623.75 and 46.0.2490.86 on first load of the index.html and and refreshed the tab after 3-4 times it seen reduced as below. This observation same on Win 7 and Ubuntu 14.04 as well.

# 51.0.2669.0 canary
Before: 20.415000000000003; After: 8504.240000000002; Diff: 8483.825
Before: 12.85; After: 852.1600000000001; Diff: 839.3100000000001

# 49.0.2623.75 Stable
Before: 287.6; After: 7274.845000000001; Diff: 6987.245000000001
Before: 16.015; After: 847.6700000000001; Diff: 831.6550000000001

# 46.0.2490.86 
Before: 251.34500000000003; After: 6542.665000000001; Diff: 6291.320000000001
Before: 9.315000000000001; After: 683.065; Diff: 673.75

hablich@ :cCould you please let us know which data or range need to be considered as good/Bad for further triage the issue.

Tested the issue on Mac 10.10.5 using 48.0.2564.116, canary 51.0.2669.0 with below steps:

1.Opened index.html in chrome.
2.Observed the speed before and after refreshing the page as below:

Chrome:
Before: 271.78; After: 4681.21; Diff: 4409.43
Before: 14.01; After: 4895.51; Diff: 4881.50
Before: 12.24; After: 4539.88; Diff: 4527.63

Firefox:
Before: 21.28; After: 25.21; Diff: 3.92
Before: 14.62; After: 15.18; Diff: 0.55
Before: 6.68; After: 6.83; Diff: 0.144

Please find attached screencast.

hablich@Could you please provide expected behavior screencast for better understanding the issue to triage it further.

Deleted: 591340.mp4 827 KB

591340.mp4 827 KB Download

Tested the issue on Mac 10.11.3 using chrome version 49.0.2623.87 and canary 51.0.2680.0.Observed almost similar in numbers.Please find the attached screen shot for the same.

hablich@ Please suggest the expected behavior to triage the issue further.

Thanks,

Deleted: 591340.png 50.7 KB

	591340.png 50.7 KB View Download

Cbruni@ do you think this is also because of the new JavaScript features in 49. It looks related.

Looking at the Octane CodeLoad benchmark, I can account for a 12% loading/parsing regression between roughly 46 and TOT caused by v8.
Between 49 and 51 there should be a slight improvement.

I would still attribute this to new ES6 features.
I hope I manage to get some time to run a file with thousands of function definitions against several v8 versions.

Already triage by TE , removing from triaging bucket.

We're currently trying out our new performance investigation tool to better pinpoint where we regressed.

On the following picture we can see that the biggest regression (despite the possible parser improvements) happened between 50 and 51 (a +5% on the Group-Total).
Note the comparison for items other than the Total are quite off due to how we measured the older versions.
We will have to rerun the measurements for adwords as the error-rates are rather high (in the order of the tracked changes), so we cannot give a detailed analysis yet based on our new tool.

Deleted: adwords-regression.png 103 KB

	adwords-regression.png 103 KB View Download

Just reran the v8-only part over 30 runs:
TOT (7f162db)
  avg = 3.8083870967741933
  geomean = 3.800945967553256
  result = 3.81 +/- 0.24(6.3%)

5.1 (bf95fd9)
  avg = 3.6819354838709675
  geomean = 3.673208096863653
  result = 3.68 +/- 0.26(6.98%)

So there is another regression for our TOT.

A major regression also occurred for us when loading a 2.5MB minified file of around 4K functions. This loads all at once, in one HTTP request. Although we've been noticing a steady decline in Chrome performance for this loading operation for a little while, this major regression occurred between 52 and 53 for us. It's an overall performance regression of about 20-25%.

Note that Safari ever since about Safari 6 on Mac OS X has loaded the exact same file twice as fast (actually that was *before* this regression - now it's even a wider gap between the two).

Several issues with our parser have been identified, see progress in https://bugs.chromium.org/p/v8/issues/detail?id=4947

This is issue is almost resolved.
The recent numbers on stable M55 look fairly ok again:
    Initial cold load: ~4s
    From 4th load on: ~600ms


Cold load on M56:      3.7s (partly broken, see  issue 672009 )
Cold load M51:        ~5s


Firefox 50.0.2 on the same machine:
    Initial load:     ~2.8-3.1s

On a final measurement on chrome x64 I get 2772 +/- 300ms on M57.
Hence, I'd declare success.