New issue
Advanced search Search tips

Issue 899739 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

Large amount of time spent in BackgroundHTMLInputStream::InvalidateCheckpointsBefore

Reported by d1.shel...@samsung.com, Oct 29

Issue description

UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce the problem:
1. Start chrome with '--js-flags=”--prof” --no-sandbox' flags
2. Load attached HTML file
3. Close chrome
4. Use "v8/tools/linux-tick-processor --preprocess isolate-NN.log > out.json" to process the profiling data
5. Use v8/tools/profview/index.html to visualize the out.json file

What is the expected behavior?
Very little time should be spent in BackgroundHTMLInputStream::InvalidateCheckpointsBefore, it probably shouldn't be visible in the profile data at all.

What went wrong?
Large chunks of time are spent in BackgroundHTMLInputStream::InvalidateCheckpointsBefore.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 72.0.3590.0  Channel: dev
OS Version: Ubuntu 16.04
Flash Version: 

While I was investigating bug 658131, I created a test file with lots of <script> elements to try to isolate where the overhead is that is described in that bug.

I increased the number of script elements to exaggerate the problem - the attached test case has around 22500 of them.

I added some logging in BackgroundHTMLInputStream::InvalidateCheckpointsBefore, and it shows that it's spending lots of time in UpdateTotalCheckpointTokenCount.

Adding some logging in there, it has approximately 45000 checkpoint entries, and it's counting all of them every time InvalidateCheckpointsBefore is called.

InvalidateCheckpointsBefore is being called ~43000 times during this test case, and the number of checkpoints increases from ~5000 to ~45000 over the course of the test.

It seems simple to avoid all this counting by just subtracting the "tokens_extracted_since_previous_checkpoint" value for the checkpoints that are actually invalidated during the call to InvalidateCheckpointsBefore. As far as I can see, it only seems to invalidate 1 checkpoint for each call to InvalidateCheckpointsBefore, although I'm not sure if this will necessarily be the case.

Of course, normal websites don't use anywhere near this many script elements, but it would probably a small improvement in page loading time if this was changed. I will submit a CL with a trivial candidate fix.

Hear are the numbers of checkpoints observed in this function when browsing around a few common websites, for reference:

o Gmail: ~45
o Google: ~58
o Reddit: ~90
o BBC: ~135
o BBC News: ~250
o Slashdot: ~120
o Bloomberg: ~130
o Amazon: ~300
o CNN: ~150
o Youtube.com: ~350
o Yahoo.com: ~120
o Twitter: ~90
o Linkedin: ~120
o Apple.com: ~130
o Emirates.com: ~225
 
lots-of-script-elements.html
722 KB View Download
Labels: Needs-Triage-M72
Labels: Triaged-ET TE-NeedsTriageHelp
The issue seems to be out of TE-scope as it is related to logging 
in BackgroundHTMLInputStream::InvalidateCheckpointsBefore.
Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!
Components: -Blink>HTML Blink>HTML>Parser
Labels: -Pri-2 -TE-NeedsTriageHelp Pri-3
Status: Available (was: Unconfirmed)

Sign in to add a comment