> The question is if a giant ball of Electron bloat could be dissected in a similar fashion in order to extract the important stuff and throw away the rest. I hope so.
Perhaps OSes could be smarter. After installing an app, it could monitor the "hot" paths in the code, and only load those instructions the next time the app is loaded. Also resources that are never used could be not loaded into memory. Etc. I know, it would be difficult to build this as you're basically instrumenting an app or driver and then rewriting it, but I guess it would be a great innovative feature in a time when OS research seems stagnant.
What you're describing is some combination of stuff language runtimes and linkers do (shared libraries, runtime loading, JITting) and demand paging.
It may be the case that one could optimize for the case where a bunch of applications ship that and are statically compiled but use the same underlying libraries. In this case, some agent on the system could analyze the code segments of these binaries and on demand construct shared libraries that strip the shared portion from the binaries. Subsequent invocations would load the constructed shared libraries for redundant sections.
Still, this probably wouldn't help much and would lead to its own issues. One of the problems with these flabby things is just how the runtimes are themselves constructed. You still have per process data structures you'd need to populate and they probably have fat data structures that are not very space efficient, and so on. The size of the instructions is probably not significant relatively speaking.
One trick could be to run the program in a "lazy" way. E.g. don't run a statement like "a=b+c", but evaluate it only when a is needed. This would require a complete and automatic rewrite at the assembly level, but you wouldn't be doing anything that you don't need. Then from this you could determine the "hot" paths, and optimize those for speed (translate back into non-lazy form).
I can’t find a reference now, but I believe Windows did (does?) have a page fault tracer that would preload from disk the pages that are observed to be needed. I can’t remember if this was just at boot time or for app launches too.
It helps to load the required pages into memory fast to enhance application launch times and then usual memory paging handles the rest of keeping required paths in memory.
Google says Windows\Prefetch is the directory for the cache. You could look here and see if there are any references to applications rather than just windows boot stuff.
Perhaps OSes could be smarter. After installing an app, it could monitor the "hot" paths in the code, and only load those instructions the next time the app is loaded. Also resources that are never used could be not loaded into memory. Etc. I know, it would be difficult to build this as you're basically instrumenting an app or driver and then rewriting it, but I guess it would be a great innovative feature in a time when OS research seems stagnant.