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

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


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

chromium-rel-win10

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14b403ad040000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14b403ad040000

Move SwiftShader decision from browser process to GPU process.
By zmo@chromium.org · Sat Dec 23 00:54:54 2017
chromium @ 5032192afb26a7b0e3acda4c735d1211f97bd52a

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Possibly a bug in how the SwiftShader decision is being applied.

 Issue 800010  has been merged into this issue.

First, I tried to reproduce this on my local win10 bot by faking GPUInfo as the win10-perf bot and triggering the same code path, but still, I failed to reproduce the 2M memory regression. I only see a slight 0.4M memory increase.

Second, the bots that had this regression are not exactly testing the codepath most users run into. The bots are testing codepath that falls back to SwiftShader rendering (the Matron GPU is never used. It seems the bot is running with 2006 Microsoft software renderer, usually we see that on win machines that never did any win updates and therefore without a GPU driver).

Third, such regression isn't seen on the NVidia/AMD GPU perf bots (Intel perf bot is mis-configured and is actually running without a recognized GPU).

The above three points make me feel it really not worthy engineering time further looking into this issue. Closing this as WontFix.

Ok, thank you for the write-up!