8

I'm currently design an application that involves a lot of calculation. Now I have generally two possibilities which I have both tested:

1) During startup of the application I calculated only the most important values and these values that consume a lot of time. So the user has to wait approximately 15 seconds during startup. But on the other hand a lot of user interactions require recalculation so that the user often has to wait 2-3 seconds after clicking somewhere until the application has calculated and loaded all values

2) I load everything during startup. This takes from 90 to 120 seconds... This is quite a long time, but the big advantage is that all the user interactions are executed immediately.

So what would you generally consider the better approach? Loading all time-consuming operations during startup or when needed?

RoflcoptrException
  • 2,035
  • 2
  • 17
  • 18
  • 1
    What are you calculating? Is this calculation optimal? – dbasnett Feb 27 '11 at 18:53
  • @dbasnett calculating is maybe not the optimal word... its more like a mix of database query, sound and graphics loading, some hundreds http requests etc etc.... and optimal... I don't think that it is 100% optimal but I can't see a really big fault – RoflcoptrException Feb 27 '11 at 19:38

8 Answers8

20

Startup as fast as possible, use a thread to do the most important calculations. So the user gets a feedback immediately, and can start working after 15 secs. In the background, let another thread calculate everything, so after two minutes, those 2-3 sec response times also go away.

user281377
  • 28,352
  • 5
  • 75
  • 130
  • 2
    Fast startups, toppled with anticipating expensive requests when possible, or providing graceful feedback at least, is the way to go. – Filip Dupanović Feb 27 '11 at 18:45
  • Also somehow inform the user that a background task is doing calculations during those 2 minutes. – TheLQ Feb 27 '11 at 19:25
  • @TheLQ: right, the status bar can be put to this task. – Matthieu M. Feb 27 '11 at 20:05
  • Of course a thread isn't technically necessary, as long as that work is done concurrently in the background. Anything your programming language/environment offers you. – Waquo Feb 27 '11 at 20:36
  • @Waquo: out of curiousity, if not using another thread, how is the work going to be done in the background? – Wonko the Sane Feb 27 '11 at 21:51
  • Before we had threads, we had to slice up 'background tasks' into little chunks and execute one chunk at a time on a regular timer, and then service 'GUI input loop' messages in between. Its still an effective technique - I've seen AJAX using this via setInterval(). – JBRWilkinson Feb 27 '11 at 22:43
  • @Wonko: You use whatever your language gives you, be it threads, fibers, coroutines, lightweight processes (as in Erlang). While the language runtime may execute them in several threads, that is not actually necessary for concurrency. After starting up, the main thread of the program is going to be idle, waiting for the user to do something, giving you plenty of time to execute your background-tasks. Of course they have to be non-blocking. Node.js is a nice example of a single-threaded, yet highly concurrent event-loop. – Waquo Feb 28 '11 at 01:09
6

Use a separate thread from the GUI to do whatever calculations you need. Have your form subscribe to an event and when you are done calculating fire that event so your form acts accordingly.

Don't lock the GUI, it's very, very annoying for end users and can be taken as a sign of a poor product.

In your case, display something to the user as fast as possible and do all calculations in the background.

4

Definitely never lock the UI thread for one, have feedback if you're going to keep the user waiting in unavoidable situations.

I'd say never calculate or fetch the "whole" of something in an application unless you were absolutely sure that every-time they use the application, you're sure that they will fully utilise all of that said data.

It really also depends on how volatile the data is. If it hardly changes, why do you need to recalculate every time the application starts? I'm sure there's nothing significant about an application start, so can that calculate be cached and only refreshed when the underlying values of the data change?

Waiting 1-2 minutes for a application load is out of the question for MOST situations. Like I said before, does all that data need to be available for all functions of the application?

Keep it responsive as much as you can by keeping data calculations as and when you need them. Put calculations on background threads if it's really always globally needed data. Consider some parts of the data being lazy-loaded/calculated.

I don't think what you've stated can help us give you an exact answer because we don't know the nature of the underlying data or use cases of the application.

Martin Blore
  • 4,645
  • 5
  • 29
  • 35
2

You don't explain too much what is your application and why there is a need to calculate something, so it's difficult to answer someting precise. In all cases, you say that you have a choice between letting the user wait for 15 seconds or for 90 seconds. In both cases, there is a problem. Every application I used loaded in less then ten seconds, except in some very specific circumstances (for example, Visual Studio can take up to 30 - 40 seconds when loading for the first time after a clean install).

In general, the user don't have to wait neither at startup, nor during the workflow. If the app takes 15 seconds to start, most users will attempt to never close it, or to start it when leaving take a cup of coffee. In all cases, they will probably think: "I should invest more in buying a correct software instead of loosing my precious time".

The cases when you really need a lot of calculation immediately are extremely rare and can be easily removed. For example, Adobe Lightroom, when starting, must show the last catalog with the thumbnails of the photos. When I start it with a catalog containing several hundreds of photos, 20 MB on disk per photo, it requires a lot of hard disk and CPU to load those photos, read them, make transformations (including perspective distorsion etc.) and generate a thumbnail. Actually, Lightroom spends less then five seconds to load on a not-so-new PC, because data is cached intelligently and because it doesn't show every of those hundreds of thumbnails immediately after startup, but rather one by one once the main window is already displayed.

So in your case, you should probably think less about when the user must wait, and more about how to avoid your users to waste their time.

Edit: of course, I've forgotten a group of applications which can behave differently: video games. In a video game, you can let the user wait for one minute to load graphics. This is done because 2D/3D rendering can be CPU-intensive, and you can't afford wasting machine resources loading and calculating things during the game: the visual performance must be the best possible, and game experience must be extremely smooth.

But even in this case, I think those applications try to spend less than a minute loading stuff. Or they load small chunks, letting the user start the game very fast, play smooth, but wait for free to five seconds when going from one level to another (that's what I've seen in Half Life series for example).

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
1

These values you need to calculate how do you use them? Do you simply want to display them?

You mention you can calculate them all at once, can't you store them somewhere so they don't have to be recalculated?

If this isn't an option, I would opt for using multithreading, and showing a 'calculating' animation where you want to display the values. Once the values have been calculated they can be shown.

This way the GUI doesn't lock up, which is extremely annoying. The user can still choose to abort and go to another screen, etc ...

Steven Jeuris
  • 5,804
  • 1
  • 30
  • 52
1

Can't you calculate them as you need them , then store them so they need not be calculated again?

So when you need a number check if its stored, if not Calculate it and store it.

Morons
  • 14,674
  • 4
  • 37
  • 73
1

Perception is pretty much reality. Waiting in line seems to take so much longer than when we're actually being services. It's human nature to develop a mind set that your application is slow (and will always be slow in everything it does) if we have to wait too long for it to load at the beginning.

Break the calculations if you can. Ideally, many of them would run in the background or done on an as needed basis.

JeffO
  • 36,816
  • 2
  • 57
  • 124
1

If those are my only two choices, I'll take the slow start up time. I don't mind waiting a bit for something to start, but I hate it when my system lags while I'm trying to get some work done.

Of course, no type of waiting is a good user experience, and I agree with your other respondents that you should investigate multi-threading. Obviously, if your app is almost done, you're probably not going to be able to easily "add on" multi-threading, so maybe look at it for the next version.

vjones
  • 908
  • 7
  • 11