Ask HN: Why do you waste CPU cycles?

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.

Thanks to the discussion I have realized that performance of product is much more important for the user experience than I originally have thought compared to other things like feature Y.

If the product does not have competition and is profitable you will get competitors at some point of time when they realize that they can outmatch you.

If the performance was not in the mind of the developers of the product anyone can win the competition by matching the product features and user experience, but make the user experience better by making the performance of the product better. They can even speed up the take over process by giving additional features to the customers. Once the users start to move to the competitors product because they have realized it's much better at doing the job the competitor can start to make the existing feature set user experience better like removing the really not needed additional mouse click.

The first products company will be having problems at this point, because they really need to start thinking new features the users will like and think how to make the user experience better, but to match the performance of the features they really need to start digging on the old code which might be messy as hell. Matching the performance of the competitor at this point is really costly, because you either have to create it again from scratch or start digging around the code and see where you can optimize. Once the performance has been optimized you might have lost ton of users and revenue.

While the first products company is trying to handle the performance issues the competitor will of course move further and further away and might even incrementally change some of the features of the product and at the same time teach the users to use it.

Then again if the first product had good performance from the start the competitor can not take advantage of this and you can keep up by giving the users better user experience.

Now someone give me enough money to compete with Facebook! JK.

It's usually far more complicated than a choice of language. Most of the problems I see are related to poor technique. Especially related to accessing resources.

"Browsers" are a good example of that. Often it's not the browser but networking problems, lost packets, latency, server responses, etc. Windows frequently waits 30 seconds when accessing network resource to tell you the resource is no longer available. Painful!

In my experience, fast code is usually beautifully written. Very logical and methodical. To be an awesome developer you NEED to be a perfectionist.

AND AVOID POLLING RESOURCES! Everything should be event driven. This is a concept very few developers truly understand. Events, events, events, events!

Agree that there's also a business case. However, $150ph developer who knows techniques is worth way more than 10 $15ph programmers because they implement the right solution the first time or make sensible decisions when taking shortcuts. Worth every dollar to find people who know what they're doing! You get what you pay for! (If you know what you're looking for!)

I should also add, polling is why I'm with the late Steve Jobs on HATING flash. Way too many Flash "designers" have NFC when it comes to good code, so they poll rape the CPU which is NOT good on mobile devices for battery life! Evil, evil Flash.

I know it's not always about the language choice, but it does matter too. Java for example requires easily 2 to 20 times more memory compared to c++? So why do we exchange we few fine lines of code for that memory consumption and easier cross-platform distribution?

Ugh.. Polling can seriously eat some resources for activity which really does not need to happen. :P

The worth of a programmer is completely another topic.

I disagree. If you're using Java properly then your data structures should be similar to that of C++. I've programmed assembly language, byte level machine code, C, C++, Java, C#, etc. They're all fundamentally the same. You can always use various compilers to dump to native too to overcome interpreter problems. Technique is what matters.

Duh. Of course you can use compilers to dump to native, but then why no-one is doing it? They lose the power of the jre cross-platform support, which is pretty much all of the hype of Java and argument of pretty much every developer who I have asked why they are using Java for the project instead of C++.

Yeah. I have used asm, c, c++, java, php, python, etc too. Though C# is something I will never touch because of the monstrosity developer behind it.

Some[1] programmers need to trust the compiler to do the optimisation. It's not easy.

Slow is subjective. People make weird mistakes about speed all the time. Anecdote: My dad used to move the mouse in circles (the pointer tracing many circles around his web browser window) because he 'knew' it speeded up his Internet connection.

Trimming those lost cycles causes some problems - code might be harder to read and understand; you might be introducing bugs; you might be competing with the compiler; etc etc. That's all fine if the gain is worth it, but for most people it really isn't.

It would be nice if machine start up could be a bit speedier - people seem to have forgotten about the 5 second boot of the ASUS EEE PC. I guess this is a good demonstration of the problem you talk about - vendors could tweak and recompile the linux kernel and tweak settings, but they don't.

[1] For some values of 'some' including 'most'.

I just laughed out loud. Thanks for today's laugh. I have seriously never heard that someone would think circling the mouse would make internet faster. Though I have heard of other things for making internet faster.

Well yeah optimizing that far that you are competing with the compiler is problematic, but if you can optimize your code that far you should know what the compiler actually optimizes. I'm not saying everyone should start optimizing their code to the point of having absolutely no waste in the code.

Readability of the code is much more related to naming conventions of variables and functions instead of how the loop actually reads constant size array size every time of the loop cycle.

Then again i'm annoyed at products where they just decide that they will use python for some application because it's easy to use and fast to code in and never worry about how fast it actually runs as long as it runs. Has nice graphical user interface and easy to distribute. fix some bugs if they actually are causing problems.

The short answer: Because it doesn't make business sense to.

As much as we all complain about programs being slow, at the end of the day a lot of people are not willing to pay substantially more for software that runs 10% more quickly. If you want to work spend more time developing to build a more efficient version, you need to pay your developers for that time, and you won't recoup your costs.

Compare to one of the industries where performance is focused on - Games (disclaimer: I'm a games developer). When you're making real-time games, performance does matter. There's a real, noticeable difference between frame rates (say 20fps vs 30, or 50 vs 60) that will make a big difference to how much players like your game, and ergo it will affect your bottom line.

Maybe people are not willing to pay more for software that runs faster, but I'm sure more people are willing to use your software longer time when they don't have to complain about the user experience.

In the game industry we often see the requirement of needing to buy new computer because we want to play some new game, but we have quite much accepted this because usually those games bring pretty good upgrade on the graphics. Though personally I don't know what is the current situation as I have dropped pc gaming. But I know nothing new has happened in the console side, except new games every week with similar graphics and physics, but different story and setting.

Anyway. One example where global bad image of software is easily seen is the browser wars. When majority of users started to replace their default Internet Explorer installation to alternative like Firefox. Though now the most popular is chrome. Of course the graphical user interface, other features of web browser played big role on this and much of the complain of web developers who did not want to support some browser.

Recently I have had to answer to questions like why Firefox or Chrome is taking something like 50% of cpu to render something. Of course I've asked them how many tabs they have open, etc. But the major cause I've realized is code of Facebook which does ton of stuff in the browser instead of in the server.

One of the business factors is the amount of competition.

If you're in a field where specific features dominate, then sub-second performance differences likely won't make a difference. Modern web browsers are roughly equivalent in feature support, so performance is one of the deciding factors for users. (If you had a web browser which didn't have CSS support but which was 100x faster in page display and Javascript performance, then I suspect you'll have few users)

Now, orders of magnitude performance differences might affect things, but then that's changing the market.

It's true that in a competition where features dominate the performance won't make much difference, but what if your competitor realizes this and matches your feature set with better performance? You just lost pretty much all of your users when your users notice this and move as the competitors users and even if you try to push some new feature your competitor will do it too. So i'm just saying worry about the performance, because if your business actually is good you will get competitors at some point.

Though social networking is annoying because count of users in the network is pretty much a feature of the network. One of the things I think Google never has realized. With larger amount of users you have feature domination easily and the users will keep using your network even if it's slow.

Actually here in Finland we have one major community site which is one of the slowest and most bad mouthed service everyone use it because the users are there and not somewhere else.

Then you're SOL. That's part of being in a competitive environment.

It doesn't happen that often. Features are hard. Performance is hard. Features and performance is very hard. If a company can pull of both then it deserves the new customers.

Often it doesn't really matter which language you use. Your webapp written in C will be just as slow as one written in PHP if the queries you're writing are poor.

It is absolutely possible to write very fast applications in 'slow' languages by writing optimised code, optimised queries and caching intelligently.

If you see a slow application, chances are it's not slow because of the technology that the developer/company picked, it's probably slow because they just didn't care enough to make it fast.

I agree that sometimes the language you use does not matter, but how the developer does not care about the speed of his application. I am asking why the developer is wasting those CPU cycles.

Anyway comparing web site backend with compiled C to interpreted PHP is bad example when the language really does not matter as C is faster than any other language and PHP being one of the slowest.

Comparing python and php is another thing when both of them actually are interpreted languages and used for scripting web servers.

Anyway this is one place where personally even I do exchange cpu cycles for speed of development. The SQL queries will affect the same both of those languages.

Yes you can make any code to be fast it only needs to be optimized and compiled to binary.