App startup time
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
Tell them to get a faster computer. Todd Smith
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
Your splash screen should be written so it does not slow down load time, but unless you can give meaningful options, your app should not start until it has the stuff loaded that it needs. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "But there isn't a whole lot out there that pisses me off more than someone leaving my code looking like they leaned on the keyboard and prayed that it would compile. - Jamie Hale, 17/4/2002
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
I'd just disenable the drop downs until they were loaded. Apps that load too slowly like Visual Studio are a pain. Regardz Colin J Davies
Sonork ID 100.9197:Colin
"real Americans don't criticize their leaders - because they don't want the terrorists to win." -- Quote from Chris Losinger a real American"
-
Your splash screen should be written so it does not slow down load time, but unless you can give meaningful options, your app should not start until it has the stuff loaded that it needs. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "But there isn't a whole lot out there that pisses me off more than someone leaving my code looking like they leaned on the keyboard and prayed that it would compile. - Jamie Hale, 17/4/2002
Christian Graus wrote: Your splash screen should be written so it does not slow down load time The splash screen is purely static, just like the ones in Word etc. It just displays registration, version information etc. I was thinking that actually making it more complex, with an animation or something, might decrease the feeling of waiting. Christian Graus wrote: unless you can give meaningful options, your app should not start until it has the stuff loaded that it needs Part of the problem is that what is meaningful, depends on what you want to do with the software. The slow part is the file access, and sometimes, you need that, but other times you dont. I cant predict what the user wants to do today :) I was thinking of starting a new thread to go through the files, so that the program would load progressively. You could start using the program immediately, but if you wanted to use one of the files starting with Z, you might have to wait a bit. I guess the question is, which is better (perception wise, for the user), a 5 second wait where the software loads, or 5, 1 second waits, as it loads progressively. -- David Wengier Sonork ID: 100.14177 - Ch00k
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
My personal preference is to have a splash screen that disappears as soon as the user clicks on it (I *hate* splash screens that sit on the top of the other windows for ages, meaning you effectively can't do anything till it's become bored and wandered away). Allow the main app to be active ASAP, but disable whatever functionality that relies on the lists being populated, and show the user the progress of the lists being loaded. Also allow the user to minimise the window during the load. This way they can fire it up, minimise it for 10 secs (or whatever) while they finish off that email or IM conversation, then pop the app back up and know when it will be done loading. Users don't generally mind if an app is unusable because of background processing as long as they have an idea of how long it will be unresponsive for. cheers, Chris Maunder
-
I'd just disenable the drop downs until they were loaded. Apps that load too slowly like Visual Studio are a pain. Regardz Colin J Davies
Sonork ID 100.9197:Colin
"real Americans don't criticize their leaders - because they don't want the terrorists to win." -- Quote from Chris Losinger a real American"
****Colin Davies wrote: Apps that load too slowly like Visual Studio are a pain. VC++ 6.0 opens in less than a second for me ;P -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
Do the drop down lists need to be fully populated on startup? Couldn't you perhaps add a filter to allow the user to determine what should be in the list? If that can't be done, you can always do what one of my colleagues did before he found ways to speed up his app - he started Solitaire on the app startup.:)
-
****Colin Davies wrote: Apps that load too slowly like Visual Studio are a pain. VC++ 6.0 opens in less than a second for me ;P -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.
Jack Handy wrote: VC++ 6.0 opens in less than a second for me One second is a long time to wait. Regardz Colin J Davies
Sonork ID 100.9197:Colin
"real Americans don't criticize their leaders - because they don't want the terrorists to win." -- Quote from Chris Losinger a real American"
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
If the app is already useful before the DD's are populated, show the mainframe, disable the DD's and shop "Populating..." in them, populate in background. Advanced: Have them enabled, populate them in background, and if someone clicks them open or selects items, show a progress dialog until you're complete Other option: Show feedback about at the startup, make sure it doesn't increase load time by more than 10% (that's a random figure yours truly thinks is good) Other option: can you cache the information for the next startup? There is a (remote) possibility that a file/folder is deleted behind your back anyway; so the code that gracefully handles "selected folders is not there".
the programmers just set it so that when in doubt, the women still think they're involved with you. It's much less frustrating that way - BGII Quest Directory
-
If the app is already useful before the DD's are populated, show the mainframe, disable the DD's and shop "Populating..." in them, populate in background. Advanced: Have them enabled, populate them in background, and if someone clicks them open or selects items, show a progress dialog until you're complete Other option: Show feedback about at the startup, make sure it doesn't increase load time by more than 10% (that's a random figure yours truly thinks is good) Other option: can you cache the information for the next startup? There is a (remote) possibility that a file/folder is deleted behind your back anyway; so the code that gracefully handles "selected folders is not there".
the programmers just set it so that when in doubt, the women still think they're involved with you. It's much less frustrating that way - BGII Quest Directory
Firstly, thanks everyone for your help. peterchen wrote: If the app is already useful before the DD's are populated, show the mainframe, disable the DD's and shop "Populating..." in them, populate in background Almost finished doing that, though your idea of catching the drop down is a very good one :) peterchen wrote: Other option: can you cache the information for the next startup? There is a (remote) possibility that a file/folder is deleted behind your back anyway; so the code that gracefully handles "selected folders is not there". I had thought of that, but the files will all be moving to a proper DB soon, so its probably not worth the effort. -- David Wengier Sonork ID: 100.14177 - Ch00k
-
Your splash screen should be written so it does not slow down load time, but unless you can give meaningful options, your app should not start until it has the stuff loaded that it needs. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "But there isn't a whole lot out there that pisses me off more than someone leaving my code looking like they leaned on the keyboard and prayed that it would compile. - Jamie Hale, 17/4/2002
Christian Graus wrote: Your splash screen should be written so it does not slow down load time It also should not force itself on top of all other windows (
WS_EX_TOPMOST
?). If an app takes a long time to load, I may want to continue working in another window, not sit and stare at another stupid splash screen, no matter how pretty it may be. :mad: Bruce Duncan CP#9088, CPUA 0xA1EE, Sonork 100.10030
Hi everyone. My name's Bruce. And I suffer from VB. -
Christian Graus wrote: Your splash screen should be written so it does not slow down load time It also should not force itself on top of all other windows (
WS_EX_TOPMOST
?). If an app takes a long time to load, I may want to continue working in another window, not sit and stare at another stupid splash screen, no matter how pretty it may be. :mad: Bruce Duncan CP#9088, CPUA 0xA1EE, Sonork 100.10030
Hi everyone. My name's Bruce. And I suffer from VB.I am happy to say "not guilty", but now that you mention, i cant think of a program I have that does that :confused: I can see how it would be annoying though :) -- David Wengier Sonork ID: 100.14177 - Ch00k
-
Jack Handy wrote: VC++ 6.0 opens in less than a second for me One second is a long time to wait. Regardz Colin J Davies
Sonork ID 100.9197:Colin
"real Americans don't criticize their leaders - because they don't want the terrorists to win." -- Quote from Chris Losinger a real American"
If you're travelling extremely close to the speed of light, yes :) Simon Q: Why didn't Intel call the Pentium the 586? A: Because they added 486 and 100 on the first Pentium and got 585.999983605. Sonork ID 100.10024
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
IMHO, you should: 1. Disable the splash screen. It's annoying. 2. Show the main screen. 3. At the top of your main function, start another thread to load data for the combos. More important: 4. If there's so much data to load, there's something really weird about your UI. Selecting an item in a 30,000 items listbox is awful! Maybe a "search" button and a listview with only the data needed being displayed would make your UI instantaneous. Crivo Automated Credit Assessment
-
Christian Graus wrote: Your splash screen should be written so it does not slow down load time The splash screen is purely static, just like the ones in Word etc. It just displays registration, version information etc. I was thinking that actually making it more complex, with an animation or something, might decrease the feeling of waiting. Christian Graus wrote: unless you can give meaningful options, your app should not start until it has the stuff loaded that it needs Part of the problem is that what is meaningful, depends on what you want to do with the software. The slow part is the file access, and sometimes, you need that, but other times you dont. I cant predict what the user wants to do today :) I was thinking of starting a new thread to go through the files, so that the program would load progressively. You could start using the program immediately, but if you wanted to use one of the files starting with Z, you might have to wait a bit. I guess the question is, which is better (perception wise, for the user), a 5 second wait where the software loads, or 5, 1 second waits, as it loads progressively. -- David Wengier Sonork ID: 100.14177 - Ch00k
I'd put a progress bar on the splash window, and perhaps text next to the bar that tells you what the app is currently loading - that way it's totally obvious to the user that something is happening, and it means if the app should ever suffer from a bug that causes it to crash when starting, your users will be able to tell you roughly where it happened -- Help me! I'm turning into a grapefruit!
-
This could be the wrong forum, but who really knows in the global scheme of things. I am trying to get my app to load as fast as possible, and I have come across a philosophical question of sorts. I already have a splash screen, so the user knows that "something" is happening, but it is sitting there for what seems like a long period of time. Is it better to show the main app screen as quickly as possible, but with reduced functionality, or wait till everything is ready before allowing the user to use the software. In this case, there are two drop down lists that need to be populated, with data read from one file per list entry, and that is what is slowing it down. -- David Wengier Sonork ID: 100.14177 - Ch00k
No one seems to have asked an obvious to me at least question, which is have you done any profiling? If you are lucky you may find that some simple tweaks here and there will speed things up no end. If not then multi-threading and/or load on demand is the way I'd go. Neville Franks, Author of ED for Windows. www.getsoft.com
-
Christian Graus wrote: Your splash screen should be written so it does not slow down load time The splash screen is purely static, just like the ones in Word etc. It just displays registration, version information etc. I was thinking that actually making it more complex, with an animation or something, might decrease the feeling of waiting. Christian Graus wrote: unless you can give meaningful options, your app should not start until it has the stuff loaded that it needs Part of the problem is that what is meaningful, depends on what you want to do with the software. The slow part is the file access, and sometimes, you need that, but other times you dont. I cant predict what the user wants to do today :) I was thinking of starting a new thread to go through the files, so that the program would load progressively. You could start using the program immediately, but if you wanted to use one of the files starting with Z, you might have to wait a bit. I guess the question is, which is better (perception wise, for the user), a 5 second wait where the software loads, or 5, 1 second waits, as it loads progressively. -- David Wengier Sonork ID: 100.14177 - Ch00k
Why don't you make the splash screen show a text progress bar that describes what it's doing (don't forget to give them an hourglass cursor dduring the process). "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
IMHO, you should: 1. Disable the splash screen. It's annoying. 2. Show the main screen. 3. At the top of your main function, start another thread to load data for the combos. More important: 4. If there's so much data to load, there's something really weird about your UI. Selecting an item in a 30,000 items listbox is awful! Maybe a "search" button and a listview with only the data needed being displayed would make your UI instantaneous. Crivo Automated Credit Assessment
Daniel Turini wrote: At the top of your main function, start another thread to load data for the combos This is basically what I have done (for one of the combos). I have put a progress bar in the combo, written "Loading..." next to it, and put it in a thread. Works quite well, and the combo I have done it for is not a high priority thing, so doesnt matter if it takes a while. The other combo is the most important one. Daniel Turini wrote: If there's so much data to load, there's something really weird about your UI. Selecting an item in a 30,000 items listbox is awful! There are only about 250 entries, sometimes only 50, but it still takes a while. The problem is that each file needs to be opened and the first record extracted. It then is put into the combo and sorted as it goes. The next version of the software will expand that to 1400 items, and will be redesigned to add a search feature (and also work from a properly indexed database). At the moment, 50 share codes sorted alphabetically is not a problem. -- David Wengier Sonork ID: 100.14177 - Ch00k
-
Jack Handy wrote: VC++ 6.0 opens in less than a second for me One second is a long time to wait. Regardz Colin J Davies
Sonork ID 100.9197:Colin
"real Americans don't criticize their leaders - because they don't want the terrorists to win." -- Quote from Chris Losinger a real American"
****Colin Davies wrote: One second is a long time to wait. Good thing it opens in less than a second for me ;) -Jack To an optimist the glass is half full. To a pessimist the glass is half empty. To a programmer the glass is twice as big as it needs to be.