4 ms·

AFAIK the difference is Safari is not as secure as Chrome. Chrome's multi-process security comes at a cost in that pretty much everything a webpage wants/needs

AFAIK the difference is Safari is not as secure as Chrome. Chrome's multi-process security comes at a cost in that pretty much everything a webpage wants/needs to do needs to be shuttled between processes. All network request, all disk io, all graphics happen in other processes. The communication overhead between processes is the difference in CPU usage. It's also why Chrome has 10x less code execution bugs than Safari. Note: Chrome doesn't have 10x less bugs. It has the same number of bugs. It's just by category of bugs it has 10x less code execution bugs. http://www.cvedetails.com/product/2935/Apple-Safari.html?vendor_id=49 http://www.cvedetails.com/product/2935/Apple-Safari.html?ven... http://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 http://www.cvedetails.com/product/15031/Google-Chrome.html?v... I'm only guessing that as Firefox goes multi-process for security reasons the same thing will happen. Their CPU usage will go up because of the overhead of cross process communication but their code execution bug percentage will go down

kitsunesoba 10y ago
Safari has been multi process for ages now (several years). I don't think that's the difference. I think Safari simply errs on the side of better resource consumption where Chrome's highest priority is cutting edge shinies for web front end devs and being as fast as possible at the cost of everything else. One example of this is where Safari will suspend tabs (as in slow them down or freeze them while keeping them in memory) you haven't used in 15+ minutes that aren't playing music for anything. Effectively, this means that Safari's total power impact is only that of the 2-4 tabs you're currently actively using instead of how ever many you actually have open. It's a bit nicer than something like The Great Suspender though, since it doesn't just trash the loaded pages and force you to reload upon visiting said tabs. If you're using an adblocker based on WebKit Content Blockers, that can have an impact too. They're much more efficient than even uBlock and add almost no additional CPU or RAM usage to web browsing, meaning you fully reap all the savings of blocking ads and egregious JS.
- LeoNatan25 10y ago
  While technically true for Safari, all these advantages are true if you develop your own application using WKWebView. Each web view will consume its own process up to a point, then some processes will be reused; inactive processes will throttle down activity and suspect. The WebKit2 architecture is a lot more efficient in its memory managed as well. It's a shame so many browsers went with Blink rather than use WebKit2, mostly for political reasons.
  - kitsunesoba 10y ago
    I think the bigger problem with WebKit-based browsers on platforms other than macOS is the frequency of updates. For example, I find GNOME Web on Linux/*BSD perfectly suited for my own web browsing, but depending on the distribution you're using updates can be fewer between than even Safari's once-per-year big updates and far more infrequent than Safari Technology Preview's or Chrome's update schedule. There aren't really any good WebKit-based options on Windows, though. IIRC Midori runs on Windows but is GTK based and feels out of place.
LeoNatan25 10y ago
WebKit2 behaves in the same way with regards to the points mentioned above. The sandboxed content process(es) are responsible for network, IO, layout, etc. The UI process (normally, the browser process) serves only as a broker for developer decision making and final drawing of the laid out content. See https://trac.webkit.org/wiki/WebKit2#ProcessArchitecture https://trac.webkit.org/wiki/WebKit2#ProcessArchitecture
- greggman 10y ago
  AFAIK WebKit2 does not use a separate process for graphics. Graphics calls go directly into whatever api is appropriate (CoreGraphics, OpenGL). Where as Chrome that's not the case, all OS/Driver level graphics happen in the GPU process. That means all data has to be shuttled from the process that wants to display the data to the GPU process. Even video for example gets decoded in a secure process (because there might be exploitable bugs in the codecs) then that data has to be shuttled to the GPU process so it can be composited with the page. The directives of compositing happen in the render process (the webpage) but eventually have to translated to graphics commands that happen in the GPU process. None of this is true in WebKit2 AFAIK and is one of the many reasons it has so many move code exploit bugs (15x actually for 2016).

kitsunesoba 10y ago

Safari has been multi process for ages now (several years). I don't think that's the difference. I think Safari simply errs on the side of better resource consumption where Chrome's highest priority is cutting edge shinies for web front end devs and being as fast as possible at the cost of everything else. One example of this is where Safari will suspend tabs (as in slow them down or freeze them while keeping them in memory) you haven't used in 15+ minutes that aren't playing music for anything. Effectively, this means that Safari's total power impact is only that of the 2-4 tabs you're currently actively using instead of how ever many you actually have open. It's a bit nicer than something like The Great Suspender though, since it doesn't just trash the loaded pages and force you to reload upon visiting said tabs. If you're using an adblocker based on WebKit Content Blockers, that can have an impact too. They're much more efficient than even uBlock and add almost no additional CPU or RAM usage to web browsing, meaning you fully reap all the savings of blocking ads and egregious JS.

LeoNatan25 10y ago
While technically true for Safari, all these advantages are true if you develop your own application using WKWebView. Each web view will consume its own process up to a point, then some processes will be reused; inactive processes will throttle down activity and suspect. The WebKit2 architecture is a lot more efficient in its memory managed as well. It's a shame so many browsers went with Blink rather than use WebKit2, mostly for political reasons.
- kitsunesoba 10y ago
  I think the bigger problem with WebKit-based browsers on platforms other than macOS is the frequency of updates. For example, I find GNOME Web on Linux/*BSD perfectly suited for my own web browsing, but depending on the distribution you're using updates can be fewer between than even Safari's once-per-year big updates and far more infrequent than Safari Technology Preview's or Chrome's update schedule. There aren't really any good WebKit-based options on Windows, though. IIRC Midori runs on Windows but is GTK based and feels out of place.

LeoNatan25 10y ago

WebKit2 behaves in the same way with regards to the points mentioned above. The sandboxed content process(es) are responsible for network, IO, layout, etc. The UI process (normally, the browser process) serves only as a broker for developer decision making and final drawing of the laid out content. See https://trac.webkit.org/wiki/WebKit2#ProcessArchitecture https://trac.webkit.org/wiki/WebKit2#ProcessArchitecture

greggman 10y ago
AFAIK WebKit2 does not use a separate process for graphics. Graphics calls go directly into whatever api is appropriate (CoreGraphics, OpenGL). Where as Chrome that's not the case, all OS/Driver level graphics happen in the GPU process. That means all data has to be shuttled from the process that wants to display the data to the GPU process. Even video for example gets decoded in a secure process (because there might be exploitable bugs in the codecs) then that data has to be shuttled to the GPU process so it can be composited with the page. The directives of compositing happen in the render process (the webpage) but eventually have to translated to graphics commands that happen in the GPU process. None of this is true in WebKit2 AFAIK and is one of the many reasons it has so many move code exploit bugs (15x actually for 2016).