I suspect that the launch windoid that indicates progress will eventually fall by the wayside after the code is tightened up and the new SQL db is in place (since that is at the heart of what takes the app a long time to load) but in the meantime, it would be nice, and an easy hack, to add a disclosure triangle and an info section (á la Disk Utility) that basically just serves as an output target for the same log data that goes to Console.
(Hey Dave, FYI, even with all the important launch files are pretty well moved over to the SSD section of the hybrid Fusion Drive, the size of my venues still makes kJams load slowly, and sometimes, like after a restart, it can REALLY bog down, like five minutes to load!, since the OS seems to give disk access priority to other tasks and forces kJams to wait its turn.)
More finely detailed launch info
-
- Posts: 1292
- Joined: Sun Apr 20, 2008 9:57 am
- Location: Pittsburgh, PA
- Contact:
Re: More finely detailed launch info
i had no plans to re-work the launch-status dialog.
also i do not think i can speed up launching, beyond what will automatically happen when we switch to SQL.
also i do not think i can speed up launching, beyond what will automatically happen when we switch to SQL.
-
- Posts: 1292
- Joined: Sun Apr 20, 2008 9:57 am
- Location: Pittsburgh, PA
- Contact:
Re: More finely detailed launch info
Wouldn't it speed things up if the playlists were not loaded at startup, but rather as needed (or in the background after the full interface is up and made available to the user).
I.e., load full interface, so it can start being used, THEN start filling in the specific playlist items in order, and loading items out of order if they are accessed by the app.
So if the user clicks the disclosure triangle, if the playlist has not been loaded yet, load it now.
This would get the user interface up and running, and the app useable, over 90% faster.
I.e., load full interface, so it can start being used, THEN start filling in the specific playlist items in order, and loading items out of order if they are accessed by the app.
So if the user clicks the disclosure triangle, if the playlist has not been loaded yet, load it now.
This would get the user interface up and running, and the app useable, over 90% faster.
Re: More finely detailed launch info
sure, that would speed things up a little, probably not much, but i don't think you realize what a monumental task it is to re-write the entire disc-access subsystem to work that way. i have very little incentive to make that happen, without a thousand people screaming at me to do it. sorry 

-
- Posts: 1292
- Joined: Sun Apr 20, 2008 9:57 am
- Location: Pittsburgh, PA
- Contact:
Re: More finely detailed launch info
Just a thought:
Would it be possible for kJams to write its internal memory representation as a file on quit, along with a timestamp, and then on start up, check if the Venue directory for the current venue had changed, and if not, read that file into memory? Or even for all playlists.
Only read through the actual directory files if there has been a change since last quit.
Like, for the 64 bit version, even?
Would it be possible for kJams to write its internal memory representation as a file on quit, along with a timestamp, and then on start up, check if the Venue directory for the current venue had changed, and if not, read that file into memory? Or even for all playlists.
Only read through the actual directory files if there has been a change since last quit.
Like, for the 64 bit version, even?
Re: More finely detailed launch info
no, not really. again not without a monumental re-write of an entirely new save/load system.