Comment by dalke | Hacker News Reader

Comment by dalke | Hacker News Reader

It's wrong, or at least simplistic, to think about "wasting CPU cycles." The goal is to optimize the user experience, and performance is only one of the factors. Features, cost, portability, ease-of-use, and security are others.

Here's a clear example of the difference. One search application I read about takes 1 second to do a search, no matter what search you do. Most of the searches actually take less than 0.1 seconds but occasionally more complex ones might take the full second.

The UI always shows a 1 second search time, even for the fast searches. They designers did this so that users know exactly what to expect. Otherwise they get frustrated when they are used to an "instant" result only to have the computer seemingly hang.

(I believe this was for the Bloomberg terminal, but I can't find the reference now. The numbers of "1 second" and "0.1 second" are made up as I've forgotten the real numbers.)

So yes, in this case the program authors clearly "waste" CPU time in order to provide a specific user experience which the users wanted.

And you think this is bad because .... ?

This is nice example, but you kinda missed the point.

This search algorithm is purposely making the search engine to sleep for maximum amount of time even if the results come faster. This is really done with the user in mind like you said and not the company. They are, "The users are not stupid, they will notice if some of our searches take longer than others"

I dislike wasting cpu cycles for unrelated reasons like "Users are stupid, they wont notice that it runs slow." so lets use this because it's easy to use without considering the effect on the users.

Your question was "why do you waste your customers cpu cycles for really small difference in speed of producing the code?" It was not "why do some programmers assume that users are stupid and won't notice that software runs slow?"

To the latter, I shrug. It's a big world with lots of programmers. Some believe very strange things.

But I've seen very little code which was written slow because of a belief that the users are stupid. I've seen a lot more slow code written because the developers were stupid.

I'd be curious about the reference as well, because afaik there is nothing in the terminal that adds artificial delay. Most apps run in 100-150ms because anything longer begins to be noticeable to the user.

It looks like I can't use that as an example because I can't find the paper I read about it. I can't even remember when it was, and the only vague time association I have suggests that it was 15 years ago.

So here are some more examples: http://www.90percentofeverything.com/2010/12/16/adding-delay... . One is:

> One of the things they found in user testing was that when new users clicked “Create my Blog” on the last step of the setup process, they were confused at how quickly their blog was created. “That’s it? Is something wrong?” were the types of things people said. So they added an interstitial “Creating your blog…” type page that did nothing but spin a little animated gif and wait a few seconds before sending new users to the “Yay, your blog is created! page”. Users were far more satisfied with the new experience that took longer.”

Another example (in addition to the Coinstar one) is by a commenter at the bottom of the page.

Reply on news.ycombinator.com