New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 836471 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

12.8% regression in smoothness.tough_path_rendering_cases at 548411:548617

Project Member Reported by briander...@chromium.org, Apr 24 2018

Issue description

See the link to graphs below.
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Apr 24 2018

All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=836471

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=25df9e138799b1e003aad8ba7f4ebcd5faac36d53d30cc44eac12ee644b8ffed


Bot(s) for this bug's original alert(s):

win-high-dpi
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Apr 25 2018

Cc: pmonette@chromium.org rkaplow@chromium.org
Owner: pmonette@chromium.org
Status: Assigned (was: Untriaged)
📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/148f6529c40000

Adding fieldtrial config for the IncompatibleApplicationsWarning feature by pmonette@chromium.org
https://chromium.googlesource.com/chromium/src/+/7a86e22e588d7941bde54bdb4a8c58c23e502836

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions
Cc: senorblanco@chromium.org
+senorblanco@chromium.org

Hi,

I have cc'ed you because you are owner of the benchmark.

Would you be able to give me a few pointers to help me understand this regression?

I clearly see the increase but I can't seem to find anything useful in the trace that explains it.
Status: WontFix (was: Assigned)
Closing this bug

Increased CPU time is totally expected from my feature. But the extra work is scheduled on a background thread and should not interfere with foreground work.

In addition, the extra work I am doing is a one time occurrence, that happens shortly after startup. A series of tasks is posted sequentially for each loaded DLL in the process (InspectModule() in module_info_win,h), and each tasks takes less than a second. It may seem long but keep in mind that this runs on a background task. Our metrics shows that the median amount of loaded DLLs for users in the wild is 120.

So unless we see more pref regressions that doesn't involve CPU time, this is working as intended.
Actually, this isn't a CPU regression, it's a rendering performance regression (frame_times = ms per frame, essentially). The test runs for 20 seconds, so if the check is only done once, it shouldn't impact frame_times.

If you want to test it locally, you can use this URL: http://rawgit.com/WebKit/webkit/master/PerformanceTests/MotionMark/developer.html?test-name=Strokeshapes&test-interval=20&display=minimal&tiles=big&controller=fixed&frame-rate=50&kalman-process-error=1&kalman-measurement-error=4&time-measurement=performance&suite-name=Canvassuite&complexity=1000'

(from tools/perf/page_sets/rendering/tough_path_rendering_cases.py)
Status: Assigned (was: WontFix)
Thanks for the info. I'll take a look at it in more details.
friendly ping from today's perf sheriff
any update?

Sign in to add a comment