> However, when I say that I want a program to start up fast, I mean that I want it to start being useful fast. Quite a few of author's ideas are not about bootstrapping gradually, they're about faking it.
But quite a few of those ideas are useful.
The only ones I thought were a bit out-there were the ones about "just processing it in the cloud" while the local copy is still loading. But other HNers are probably more qualified to judge how realistic this is.
What is a possibility, however, during loading a lot of time is spent on loading all sorts of modules, ones that might not even be used that session, and most definitely not in the first few minutes. Because what is the user going to do first? Most likely it'll be `File > Open ...` and browsing through the filesystem looking for whatever project they intend to open.
You don't need any plugins for that. And it's exactly the type of task that spends relatively a lot of time waiting for user input and not so much time computing or loading things. During this task the app can continue loading modules and plugins and the user doesn't have to wait because they're selecting a file.
You probably need to disable (most of) the instant preview in the file open dialog until it's done loading, but that's a minor trade-off.
Of course you're loading the modules necessary for opening files first (most recently used filetypes first). When that's done the dialog can start showing previews. If the user happens to have found and selected their file before it's done, then, only then they'll have to wait.
Now you're loading the file and it's showing on the screen, the user can browse the layers a bit and ponder where exactly they left off last time. A wonderful time to load the rest of the modules! Of course the features used in this project will be loaded first. If there's no text layers, we can put off loading font-rendering support in favour of other modules.
It's not all load-on-demand, but a lot of user tasks are not as processor- or data-intensive as you'd think, because the user is busy thinking and as long as the UI is responsive enough they're happy.
But quite a few of those ideas are useful.
The only ones I thought were a bit out-there were the ones about "just processing it in the cloud" while the local copy is still loading. But other HNers are probably more qualified to judge how realistic this is.
What is a possibility, however, during loading a lot of time is spent on loading all sorts of modules, ones that might not even be used that session, and most definitely not in the first few minutes. Because what is the user going to do first? Most likely it'll be `File > Open ...` and browsing through the filesystem looking for whatever project they intend to open.
You don't need any plugins for that. And it's exactly the type of task that spends relatively a lot of time waiting for user input and not so much time computing or loading things. During this task the app can continue loading modules and plugins and the user doesn't have to wait because they're selecting a file.
You probably need to disable (most of) the instant preview in the file open dialog until it's done loading, but that's a minor trade-off.
Of course you're loading the modules necessary for opening files first (most recently used filetypes first). When that's done the dialog can start showing previews. If the user happens to have found and selected their file before it's done, then, only then they'll have to wait.
Now you're loading the file and it's showing on the screen, the user can browse the layers a bit and ponder where exactly they left off last time. A wonderful time to load the rest of the modules! Of course the features used in this project will be loaded first. If there's no text layers, we can put off loading font-rendering support in favour of other modules.
It's not all load-on-demand, but a lot of user tasks are not as processor- or data-intensive as you'd think, because the user is busy thinking and as long as the UI is responsive enough they're happy.