0

Assume an application that shows a data table. The data is loaded from a database when the program is initialized.

Each value in the table is represented by an input field, where each keypress in one of those fields causes a refresh:

  • The data is written to the database
  • Then, each value in the table is refreshed by reassigning the models to the data

My concern here is that each value is getting updated in order to recompute a summary, even those that weren't touched at all.

Yet, the application runs fast, the update is not causing any inconvenience to the user. Should I refactor my application nevertheless?

Wottensprels
  • 286
  • 1
  • 3
  • 10
  • 2
    No loss of convenience? Well, maybe not now. What if the data set grows? Maybe not on *your* machine. What about the basic office shlub's outdated desktop box? Maybe not to you. What about people who have to use this a thousand times a day? – Kilian Foth Sep 17 '14 at 06:40
  • Have to add a straw man argument to @Kilian 's. Conventional wisdom is optimization should only be done when you know you have a problem and only after profiling to find the cause of the problem, and only by experts. – mattnz Sep 17 '14 at 07:03
  • It's not a strawman. Those aren't rhetorical questions, they're actual questions. If the answer is "no" to all of them, then "Don't worry about performance here" is a perfectly acceptable decision. – Kilian Foth Sep 17 '14 at 07:44
  • 1
    My experience is that incremental updates are very error prone and hard to debug. I only use them when recomputing is too costly. – CodesInChaos Sep 17 '14 at 08:07
  • @mattnz What do you mean by "and only by experts"? If I'm not an "expert" am I not allowed to optimize? – Idan Arye Sep 17 '14 at 08:41
  • caring about performance is not the same as optimization. – Pieter B Sep 17 '14 at 10:12
  • @IdanArye Sure a novice can optimize code, just like a novice programmer can write code. – Jeffery Thomas Sep 17 '14 at 10:58

2 Answers2

3

I agree that accessing the database on every key press is not an optimal design. I would not recommend that you write it that way if you were starting from scratch.

However, as a general rule, don't rewrite working code without a good reason. If the application performs well, there is no reason to change it. Just make sure that your assessment of the application as "fast" holds up in your real-world use case. This means testing with enough records and enough concurrent connections to replicate what you expect in production.

  • 1
    and with enough simultaneous connections... I've seen applications perform briliantly as long as no more than 10 people used them, 11th person logs in and everything goes south. – jwenting Sep 17 '14 at 09:39
  • @jwenting, yep, that's why I mentioned that! –  Sep 17 '14 at 09:53
2

Quote from Nielsen. Response Times: The 3 Important Limits

The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]:

  • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
  • 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
  • 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.

If you're designing GUI applications, performance should always be on your mind. If you should re-factor your current application however depends if the time investment is worth it.

Community
  • 1
Pieter B
  • 12,867
  • 1
  • 40
  • 65