I have recently started to think more why almost every one of my friends complain to me how the applications they use are slow.<p>Personally I prefer to write my code in the programming language which has the best performance for the task with possibly extensive standard libraries. This does not mean I would program the next generation games in assembly, because I know the development cycle speed is important too.<p>Some years back my friends who actually are regular users and might not even know how to upload a video to youtube it was always about how Windows XP was getting slow after some months of use. Then it was about Vista being horribly slow. Now it's about browsers being slow as they can not complain about Windows 7 that much.<p>I know that you can write horrible and slow code in any language and I'm not saying I can not write horrible code. That usually comes down to the programmers being horrible, but I know some of you guys are actually pretty awesome programmers and understand the logic behind how computers execute code.<p>The only problem I notice is that some of you will jump to the next new thing like there's nothing else if it does the task even though it might be slow, but is easy to use.<p>My question comes down to why do you waste your customers cpu cycles for really small difference in speed of producing the code?
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.<p>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.<p>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.<p>(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.)<p>So yes, in this case the program authors clearly "waste" CPU time in order to provide a specific user experience which the users wanted.<p>And you think this is bad because .... ?
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>"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!<p>In my experience, fast code is usually beautifully written. Very logical and methodical. To be an awesome developer you NEED to be a perfectionist.<p>AND AVOID POLLING RESOURCES! Everything should be event driven. This is a concept very few developers truly understand. Events, events, events, events!<p>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!)
Some[1] programmers need to trust the compiler to do the optimisation. It's not easy.<p>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.<p>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.<p>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.<p>[1] For some values of 'some' including 'most'.
The short answer: Because it doesn't make business sense to.<p>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.<p>Compare to one of the industries where performance <i>is</i> focused on - Games (disclaimer: I'm a games developer). When you're making real-time games, performance <i>does</i> 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.
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.<p>It is absolutely possible to write very fast applications in 'slow' languages by writing optimised code, optimised queries and caching intelligently.<p>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.