3 ms·

Yeah, agree: the really big gain would come from moving init logic from load time to install time.

• olliej 3y ago
  I'm not sure what you mean here - you can't move application launch logic to install time, it's inherently a launch time process - loading resources into memory, setting up runtime data structures, etc fundamentally requires time. Now plenty of apps have unnecessarily large start up times, but those apps can largely be improved without just doing more work at install time - it's simply that a lot of devs don't care. There's a lot of "if it's not being measured, it's not being improved" for launch time for many - most? - projects and companies that means launch time is just slow for no reason.
  • dzdt 3y ago
    you can't move application launch logic to install time, it's inherently a launch time process - loading resources into memory, setting up runtime data structures, etc That is exactly what I want to do. Imagine your system had the full 64 bit address space populated with RAM. You launch every installed application simultaneously and let them run thru init to the point where they are ready for user interaction. Then suspend the whole system to disk. Thats what I want the "applications installed" state to look like. In actual use you have limited RAM and launch applications one at a time. At launch time it is un-suspending the already initialized application. It has its own reserved virtual memory addresses so no need to reallocate new memory and no conflict with other running applications. Emacs used to do something like this (maybe still does?) but in a very hacky way. I'd like it to be how the whole OS works.
    • wbl 3y ago
      Smalltalk images are somewhat similar: the whole machine state is persisted.