3 ms·

If I quit all WebKit apps then by definition I've quit everything that loads the libraries. You also seem to be very confused as to the difference between a li

If I quit all WebKit apps then by definition I've quit everything that loads the libraries. You also seem to be very confused as to the difference between a library and a process, given what you've been saying. Having a bunch of apps using WebKit as a framework does not confer any kind of advantage on these apps. If I have an app using WebKit, and you have an app using WebKit, they don't affect each other in the slightest. The only way they would is if they were reusing shared web content processes and so didn't have to wait for those to launch, except a) I imagine launching a web content process is pretty quick, and b) they don't share web content processes so it doesn't matter.

smoldesu 4y ago
So, do it. See what happens; WebKit is still loaded via MacOS because it's used to render UI elements that are considered part of the system. Unless you've modified the way default apps run on MacOS, WebKit should be loaded into memory from the moment you boot MacOS to the moment you shut it down.
- lilyball 4y ago
  The overhead of mapping the files on disk into memory is pretty minimal. The framework still has to be initialized anew for every application. About the only benefit I can think of is WebKit might be in the dyld shared cache (assuming that includes frameworks that can be updated independently of the system), and that just means it would bypass some of the dyld setup, but if so that would just have a minor effect on the launch time of the application. Also if I actually do that right now I see a bunch of WebContent processes, the apps themselves and then there are a handful of daemons that have InfoPlist.strings open from WebKit (from the iOSSupport subsystem) but that's just a localization file and I don't know what it's doing there but it appears to be completely irrelevant (the daemons do not have anything else from WebKit loaded). AFAIK macOS does not use WebKit to render UI. iOS has been known to use WebKit for text rendering in the past, but I'm not sure if it even still does that, and that was presumably in-process anyway. And even if it did that still wouldn't matter as far as applications' own use of web rendering engines is concerned.
  - alwillis 4y ago
    > AFAIK macOS does not use WebKit to render UI Sure it does: iCal, Mail.app, iTunes (Music app), App Store, etc.
    - lilyball 4y ago
      Those aren't the OS, those are individual apps that have chosen to use a web rendering engine for various content, and it's not even correct. Calendar doesn't use WebKit at all and never has. Mail.app uses it to render external HTML input (i.e. email messages) rather than UI. I believe Music.app moved off WebKit some time ago as well, and it looks like App Store did too (Accessibility Inspector confirms that the Updates page, which used to be rendered with WebKit, is now a collection view). Both Music.app and App Store link against WebKit but that's likely because the Account Settings page is rendered with WebKit (this is likely content that is served remotely). In any case, the OS itself does not rely on WebKit for UI, it just ships some apps that use WebKit.

smoldesu 4y ago

So, do it. See what happens; WebKit is still loaded via MacOS because it's used to render UI elements that are considered part of the system. Unless you've modified the way default apps run on MacOS, WebKit should be loaded into memory from the moment you boot MacOS to the moment you shut it down.

lilyball 4y ago
The overhead of mapping the files on disk into memory is pretty minimal. The framework still has to be initialized anew for every application. About the only benefit I can think of is WebKit might be in the dyld shared cache (assuming that includes frameworks that can be updated independently of the system), and that just means it would bypass some of the dyld setup, but if so that would just have a minor effect on the launch time of the application. Also if I actually do that right now I see a bunch of WebContent processes, the apps themselves and then there are a handful of daemons that have InfoPlist.strings open from WebKit (from the iOSSupport subsystem) but that's just a localization file and I don't know what it's doing there but it appears to be completely irrelevant (the daemons do not have anything else from WebKit loaded). AFAIK macOS does not use WebKit to render UI. iOS has been known to use WebKit for text rendering in the past, but I'm not sure if it even still does that, and that was presumably in-process anyway. And even if it did that still wouldn't matter as far as applications' own use of web rendering engines is concerned.
- alwillis 4y ago
  > AFAIK macOS does not use WebKit to render UI Sure it does: iCal, Mail.app, iTunes (Music app), App Store, etc.
  - lilyball 4y ago
    Those aren't the OS, those are individual apps that have chosen to use a web rendering engine for various content, and it's not even correct. Calendar doesn't use WebKit at all and never has. Mail.app uses it to render external HTML input (i.e. email messages) rather than UI. I believe Music.app moved off WebKit some time ago as well, and it looks like App Store did too (Accessibility Inspector confirms that the Updates page, which used to be rendered with WebKit, is now a collection view). Both Music.app and App Store link against WebKit but that's likely because the Account Settings page is rendered with WebKit (this is likely content that is served remotely). In any case, the OS itself does not rely on WebKit for UI, it just ships some apps that use WebKit.