Can you please provide a sample testcase for the ease of finding regression.

This is a copy of the script I use 

Deleted: generareporte2.php 2.6 KB

generareporte2.php 2.6 KB View Download

The script don't have a database connection but even so the script breaks

I've founded that Chrome crashes because of the RAM consumption, but it's only a big table and I have 6 GB of RAM... Someone knows if theres a way to avoid this problem 

175,000 rows seems like a big table to me. I'm not sure it's reasonable to expect it to render without running out of memory.

If you can find a way to reproduce it with just static data it will be easier for us to reproduce. Setting component to Blink>HTML for triage.

This is the example with static data.

Deleted: generareporte2.php 2.6 KB

generareporte2.php 2.6 KB View Download

@ricea -- A friendly ping. Could you please look into the Comment #6.
Thanks!

Unable to reproduce this issue on Mac 10.12.6 with chrome #61.0.3163.100, observed on loading provided file in comment #6 didn't see any crash.

steps followed:
1. Started the php server with command "php -S localhost:8000"
2. Loaded the provided php file in comment #6

Attaching the screen-cast for reference.

arthurtatu220@ Could you look into it and let us know any steps i have missed while reproducing the scenario.

Note: Unable to test this scenario on Windows and Linux machines because of unavailability of php test setup.

Thank You...

#7 Sorry for my late reply, I didn't realise I wouldn't be automatically CC'd.

Thank you for providing the repro script generareporte2.php. I ran it through php to create the static page large-table.html, which I have had to gzip to attach to this bug as it is 111M uncompressed.

In my test, it did load successfully, but it took more than 20 minutes and used 3.8G of memory. If you were using a 32-bit build of Chrome it is quite likely that it would run out of address space and crash.

Deleted: large-table.html.gz 1.4 MB

large-table.html.gz 1.4 MB Download

Using large-table.html above, bisect info: 475314 (good) - 475318 (bad)
https://chromium.googlesource.com/chromium/src/+log/69732971..505e4c3a?pretty=fuller
Suspecting r475317 "Disable style sharing outside tests"
Landed in 61.0.3115.0

Chrome 32-bit consumes 2.5GB of memory after the suspected CL, but only 1.5 - 1.8 GB in old builds:
	r346028	1.5 GB
	r417831	1.6 GB
	r475314	1.8 GB
	r475318 2.5 GB <<<<<
	r488093 2.5 GB
	r497277 2.5 GB
	r508786 2.5 GB

Chrome 64-bit memory consumption is 3.8 GB after the suspected CL, 2.5 GB in older builds.
It's 50% more than 32-bit which implies Chrome uses machine word alignment for all data structures, but is it really necessary?

Comparing callstack before and after the suspected CL reveals SharedStyleFinder::FindSharedStyle is no longer used, instead each element fires LocalFrameView::UpdateStyleAndLayoutIfNeededRecursive, which apparently explains the 50% consumption increase.

Another question is speed. Maybe Chrome can render tables faster by checking what's ahead in the html and do a bulk insertion of elements in case of a regular table structure (e.g. no col/row spans and whatnot)?

Thanks woxxom@ for bisecting!

As it looks related to disabling styleshraing - adding nainar@ in cc.

If disabling style sharing is not regressing perf at all, does this mean
we had a blind spot about memory regression for style sharing?

#11 In response to your question about alignment: except in cases where it is explicitly overridden, Chrome uses the default alignment provided by the compiler. I believe that the most significant cause of the size difference is just that the pointers are larger. Some structures have holes which get bigger on 64-bit builds. I've investigated this a bit in past; there are many holes which could be eliminated by rearranging data members, but the cases in which this would reduce the size of the structure are surprisingly few. This is because of the padding at the end of the structure.

Thank you for the outstanding work bisecting this, by the way. That would have taken hours on my machine.

>If disabling style sharing is not regressing perf at all, does this mean we had a blind spot about memory regression for style sharing?

I think a project member should do a per-revision bisect of 475314 (good) - 475318 (bad) range (the snapshot range itself is correct) to confirm the suspected r475317.

Here's a much faster repro:
1. open the attached test.html
2. wait for the title to reach 100% (about 1-2 minutes)
3. open Chrome Task Manager, observe memory consumption of the tab
Expected:
  1.0 GB in 32-bit Chrome
  1.7 GB in 64-bit Chrome
Observed:
  1.5 GB in 32-bit Chrome
  2.3 GB in 64-bit Chrome

Deleted: test.html 2.6 KB

test.html 2.6 KB View Download

#17 Thanks for the faster repro.

I will do the per-revision bisect.

Confirmed r475317.

--

You are probably looking for a change made after 475316 (known good), but no later than 475317 (first known bad).                                                           
CHANGELOG URL:                                                                        
The script might not always return single CL as suspect as some perf builds might get missing due to failure.                                                               
  https://chromium.googlesource.com/chromium/src/+log/2da4c09d784da8f90c2e41418e92533abb9f5612..cc275c99719dca651110ad31085c6401de79056a     

Hi folks, it's interesting that this issue is platform specific. I can't repro on Mac but can on a Windows device. 

Thank you for the bisect. Given we increase the number of ComputedStyle objects created this bug is definitely an issue. Given the edge case and that no perf bots caught this, I would call this an edge case. Nonetheless will take a look to see if we can make any immediate perf gains. 

Ah, I see what you mean: this is an edge case because the regression affects only lots of identically styled elements like the insanely huge tables, which is not present on the web since it's impractical.

Yes sorry I should have been more clear. This would only impact the system where all elements are styled identically. For smaller pages we have conscientiously made the decision to take the memory hit. Our perf bots run microbenchmarks of small numbers. They did show this hit but to the great magnitude we see here. 

Thank you for your due diligence here woxxom@.

Taking a look into the numbers here, and the fact that no other site has reported this issue, I don't think short term action is possible here. We are looking into other optimizations that we can make that addresses this problem though. 

 Issue 779801  has been merged into this issue.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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