4 ms·

"drop-in feature-parity with Chromium" == They want to be able to replace Chromium with their own engine, but it must be very compatible. "duplication is becom

"drop-in feature-parity with Chromium" == They want to be able to replace Chromium with their own engine, but it must be very compatible. "duplication is becoming a significant performance drain" == Every electorn app bundles its own browser engine (as opposed to a single browser engine for the whole OS, like a shared library), which increases system RAM usage and hinders performance. "They want to single-instance Electron with their own fork" == MS wants to support electron apps but they want to use a shared browser instance for performance. They rightly believe that doing so with their own browser engine is a huge pain in the ass. Might as well just use the real Chromium for all browser needs throughout the OS including electron apps instead of trying to reimplement it.

cjbprime 8y ago
> which increases system RAM usage and hinders performance. I can see that it increases disk space, but everything on top of that is questionable. I believe DLLs will share/reuse memory pages even if they were downloaded in separate bundles.
- cwyers 8y ago
  The trouble comes if they're not the same DLLs. Chromium updates often enough that there's lots of different versions you can bundle.
  - cjbprime 8y ago
    But how would that situation be any different in the presence of some kind of system Chromium install provided by MS? Chromium updates often, so you don't want to run your client-side JS against any other Electron version than the one you wrote it for because they change APIs frequently, so you'll still have one set of DLLs for each needed Electron version.
    - cwyers 8y ago
      Given that it's Chromium (and thus effort to get things running should be minimal), and most Electron app writers aren't pushing Chromium to the bleeding edge, why wouldn't they test on the one that ships with the desktop OS with the largest installed base out there?
etaioinshrdlu 8y ago
Another thought: If the same browser shared library can be used for every process, the same RAM pages should be executed for each process, so the CPU should be able to keep more of the code in CPU cache, along with probably branch prediction statistics as well. To the CPU it is the same code running which has many performance impacts. Less code = faster.

cjbprime 8y ago

> which increases system RAM usage and hinders performance. I can see that it increases disk space, but everything on top of that is questionable. I believe DLLs will share/reuse memory pages even if they were downloaded in separate bundles.

cwyers 8y ago
The trouble comes if they're not the same DLLs. Chromium updates often enough that there's lots of different versions you can bundle.
- cjbprime 8y ago
  But how would that situation be any different in the presence of some kind of system Chromium install provided by MS? Chromium updates often, so you don't want to run your client-side JS against any other Electron version than the one you wrote it for because they change APIs frequently, so you'll still have one set of DLLs for each needed Electron version.
  - cwyers 8y ago
    Given that it's Chromium (and thus effort to get things running should be minimal), and most Electron app writers aren't pushing Chromium to the bleeding edge, why wouldn't they test on the one that ships with the desktop OS with the largest installed base out there?

etaioinshrdlu 8y ago

Another thought: If the same browser shared library can be used for every process, the same RAM pages should be executed for each process, so the CPU should be able to keep more of the code in CPU cache, along with probably branch prediction statistics as well. To the CPU it is the same code running which has many performance impacts. Less code = faster.