Extension causes excessive I/O activity between Browser and NetworkService processes of Vivaldi
With Flag Cookies==3.6.0 I have observed persistent CPU and I/O activity, which can very quickly force Vivaldi to crawl or freeze. Quoting another bug report:
Steps to reproduce:
- Load almost any page, for example https://www.empik.com/ or https://gmail.com/
- Observe Process Explorer
Address (URL) of faulty page: https://www.empik.com/
Expected behaviour: Page loads quickly, little use of resources afterwards.
Actual behaviour: CPU is constantly loaded, main process does constant I/O reads at around 27MB/s when idle, NetworkService does constant I/O writes at around 27MB/s when idle (synchronized with the main process), trying to do activities like opening new tabs racks CPU to 100% and I/O activity to the point where browser window can freeze for longer periods or even become permanently unusable with seconds of waiting for any action to take effect.
Reading process flags: "vivaldi.exe" --disable-features=UseEcoQoSForBackgroundProcess
Writing process flags: "vivaldi.exe" --type=utility --utility-sub-type=network.mojom.NetworkService --lang=en-US --running-vivaldi --service-sandbox-type=none --field-trial-handle=2264,i,15202153348528492102,9881405705248860975,262144 --disable-features=ResponsiveToolbar,UseEcoQoSForBackgroundProcess --variations-seed-version --mojo-platform-channel-handle=2260 /prefetch:3
"UseEcoQoSForBackgroundProcess" has been included after advice from the user forum, as otherwise no actions were possible within the browser, ever.
Heavy I/O does not seem to be connected to disk activity according to ProcessMonitor - there are simply no file-related events, that would correspond with that level of excessive, permanent load.
It seems that presence of the extension triggers nervous demands from Browser to NetworkService to update cookies - and the more tabs are loaded, the worse it gets, as pipe interrupts block other operations.
Idle activity:
Activity while loading second tab for several seconds already:
Thank you for your investigation and observations @mrzyglockimarcin - the most "traffic" for the addon probably arise likely due to observed "xml http requests" for cookies. And the present fact that all browser storage data of the addon is requested on a single change or update of a cookie.
I am currently reviewing some ways to reduce the amount of data processed (on reads, writes of the browser storage) by the extension to a minimum. Unfortunately I am not able to predict when this will be ready as there are some issues with that, also pointed out on the Mozilla Add on Development Discourse which (from my understanding) block the described improvements in the Discourse posting, using a small set of storage "get" and "set" helper functions. If you are keen, you can take a look at it.
Any help is much appreciated so.