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.
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.
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.
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.
My question comes down to why do you waste your customers cpu cycles for really small difference in speed of producing the code?
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 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.
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.
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.
"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!)
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.
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.
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.
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.
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'.
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.
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.
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.
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.
