Large amount of time spent in BackgroundHTMLInputStream::InvalidateCheckpointsBefore
Reported by
d1.shel...@samsung.com,
Oct 29
|
||||
Issue descriptionUserAgent: 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
,
Oct 30
,
Oct 31
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...!!
,
Nov 5
|
||||
►
Sign in to add a comment |
||||
Comment 1 by d1.shel...@samsung.com
, Oct 29