I've got another hit on this, visit the website https://maxencecyrin.fr/ and there is a similar problem. In this case I used a more extensive range and see two jumps. The first from 8% to 18% and the next from 18% to 50%.

339982 at 05% tab process and 07% main process
356544 at 05% tab process and 07% main process
364813 at 08% tab process and 05% main process
365850 at 06% tab process and 07% main process
366319 at 06% tab process and 07% main process
366347 at 08% tab process and 05% main process
366365 at 06% tab process and 07% main process
366369 at 06% tab process and 07% main process
366371 at 06% tab process and 07% main process
366372 at 09% tab process and 05% main process
366377 at 10% tab process and 05% main process
366549 at 10% tab process and 05% main process
366736 at 11% tab process and 05% main process
367587 at 10% tab process and 05% main process
372082 at 09% tab process and 07% main process
406730 at 09% tab process and 08% main process
485046 at 11% tab process and 05% main process
485435 at 08% tab process and main process unrecorded
485468 at 09% tab process and main process unrecorded
485486 at 08% tab process and main process unrecorded
485492 at 08% tab process and 05% main process
-- 10 point jump in tab process:
485500 at 18% tab process and 05% main process
485537 at 18% tab process and main process unrecorded
485627 at 18% tab process and main process unrecorded
485748 at 18% tab process and main process unrecorded
485803 at 19% tab process and main process unrecorded
485824 at 16% tab process and main process unrecorded
485825 at 18% tab process and 05% main process
-- 32 point jump in tab process:
485861 at 50% tab process and 01% main process
485897 at 50% tab process and main process unrecorded
486194 at 50% tab process and main process unrecorded
486715 at 50% tab process and main process unrecorded


For the 10 point jump from 8% to 18%:
You are probably looking for a change made after 485492 (known good), but no later than 485500 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/a87cc6b7d71388830b2c56fdc188dddb9b6ef9c1..48b272671a15f02ae84cfb147c793467731eeb5f


For the 32 point jump from 18% to 50%:
You are probably looking for a change made after 485825 (known good), but no later than 485861 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/834ed117a4b677e9868556b8d7ad8d2aeb622413..2278ffaff83a13e52290b5464f6a0ada75520506

For the sake of comparison Firefox ESR averages 9% and their latest Nightly averages 12% (content+main process).

From the bisect range provided above, could this be related to this change:

Change Log: https://chromium.googlesource.com/chromium/src/+log/a87cc6b7d71388830b2c56fdc188dddb9b6ef9c1..48b272671a15f02ae84cfb147c793467731eeb5f

https://chromium.googlesource.com/chromium/src/+/1dc1c0e1ced508a0545d59cc55dbc4d16d7a8cd3

@ vmpstr: Looping you, request you to please take a look into it. Please help us to find an owner if not with respect to your change.

Thanks.!

vmpstr@ Can you please look into this issue and provide an update in ref to comment #3.


Thanks..

Attached is another example with sharex.com. It is probably temporary because their theme is snow for the season. When I maximize the window the tab eats a lot of CPU. In Firefox it only eats 12%. So maybe it's some bad javascript but in Chrome it's much worse.

python bisect-builds2.py -a win -g 464648 -b 508578 --use-local-cache --verify-range -- --no-first-run --disable-default-apps --no-default-browser-check --start-maximized --force-device-scale-factor=1 https://getsharex.com/

The first jump from about 15% total to 35% total is here:

Bisect info: 485825 (good) - 485861 (bad)
https://chromium.googlesource.com/chromium/src/+log/834ed117..2278ffaf

And the second jump I couldn't determine because chromium task manager kept giving wrong values like 3% or 4% even though it was eating 50%. I marked a bunch of builds as unknown but I just can't continue it's taking too long.

Deleted: high_cpu_usage_sharex_tab.gif 27.1 KB

	high_cpu_usage_sharex_tab.gif 27.1 KB View Download

Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Here's another one but I'm not sure if it's the same issue. https://www.shipmap.org/

Chrome 64.0.3282.119 - 2% CPU main process, 40% secondary process.

Firefox also uses a lot of CPU for that website.
https://bugzilla.mozilla.org/show_bug.cgi?id=1435173

As per latest comment#7 checked issue on latest stable 64.0.3282.167, on latest canary 66.0.3350.0 using Mac 10.13.3, Ubuntu 14.04 and Windows 10 with shipmap.org. CPU varies from 1.3 and some times it reaches 13.

This issue is seen from M60. Hence considering this issue as Non-Regression and marking as Untriaged.

Issue is seen in firefox as well.

Thanks!

Bruce, sending to you for triage since the initial report is on Windows.

This looks related to  crbug.com/769677  which was found to be using color profiles on Windows - see crrev.com/c/564392, which is found in the initial bisect. Adding ccameron@ for comment.

CPU sampling data suggests that most of the time in the initial Google Maps URL when scrolling around is from v8, so crrev.com/c/567623 seems like a good possibility also. Adding machenbach@ for comment.

The sampled data below is a bit tough to follow but it shows 1842 samples in the renderer process (one sample per millisecond, over 4.66 s) with 544 of those inside v8::internal::compiler::PipelineImpl::OptimizeGraph and its descendants. I tested on stable (M64).

Line #, Process, Stack, Count
 1, chrome.exe (13876), , 1842
 2, , [Root], 1837
 3, ,   |- ntdll.dll!RtlUserThreadStart, 1012
 4, ,   |    kernel32.dll!BaseThreadInitThunk, 1012
 5, ,   |    |- chrome_child.dll!base::`anonymous namespace'::ThreadFunc, 845
 6, ,   |    |    |- chrome_child.dll!base::internal::SchedulerWorker::Thread::ThreadMain, 576
 7, ,   |    |    |    chrome_child.dll!base::internal::TaskTracker::RunNextTask, 576
 8, ,   |    |    |    chrome_child.dll!base::internal::TaskTracker::RunOrSkipTask, 576
 9, ,   |    |    |    |- chrome_child.dll!base::debug::TaskAnnotator::RunTask, 575
10, ,   |    |    |    |    |- chrome_child.dll!v8::internal::OptimizingCompileDispatcher::CompileTask::RunInternal, 566
11, ,   |    |    |    |    |    chrome_child.dll!v8::internal::OptimizingCompileDispatcher::CompileNext, 566
12, ,   |    |    |    |    |    |- chrome_child.dll!v8::internal::CompilationJob::ExecuteJob, 565
13, ,   |    |    |    |    |    |    chrome_child.dll!v8::internal::compiler::PipelineCompilationJob::ExecuteJobImpl, 565
14, ,   |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::PipelineImpl::OptimizeGraph, 544
15, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::PipelineImpl::ScheduleAndSelectInstructions, 267
16, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::EffectControlLinearizationPhase::Run, 63
17, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::LoadEliminationPhase::Run, 38
18, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::EscapeAnalysisPhase::Run, 37
19, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::LateOptimizationPhase::Run, 34
20, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::PipelineImpl::Run<v8::internal::compiler::SimplifiedLoweringPhase>, 27
21, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::EarlyOptimizationPhase::Run, 25
22, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::StoreStoreEliminationPhase::Run, 16
23, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::LoopPeelingPhase::Run, 12
24, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::MemoryOptimizationPhase::Run, 10
25, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::GenericLoweringPhase::Run, 7
26, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::ControlFlowOptimizationPhase::Run, 6
27, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::ZoneStats::ReturnZone, 1
28, ,   |    |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::ZoneStats::NewEmptyZone, 1
29, ,   |    |    |    |    |    |    |- chrome_child.dll!v8::internal::compiler::PipelineImpl::AssembleCode, 21

I don't see many suspicious CLs in https://chromium.googlesource.com/v8/v8/+log/cc60e4e3..4f9afdad

CC some of the authors.

My change affects only test mode with --stress-incremental-marking flag.
"[heap] Fix infinite GC loop in stress incremental marking mode."

The only relevant change by me would be 7b08031 but it's reverted in the same roll.

Thanks, neis@.

Based on #11, assigning to the current V8 performance sheriff for proper triaging.

*** UI Mass Triage ***

Closing, since there is no updates since the past few weeks.
If you feel this issue should still be addressed, feel free to reopen it or to file a new issue.