In a recent post I discussed efficiency in IT ("The power of Ten"). I think we Software Engineers have still a long, long way to go. We focused on models, fancy user interfaces, layered architecture, abstraction from hardware, and often left an terrible efficiency mess behind us (no problem, we just add some more iron...). And the curious thing is, this is in my opinion not necessarily because of the higher abstraction level but rather due to developers that do not fully understand contemporary complex architectures and frameworks and/or do not use proper development techniques.
Ok, if a company who has an intrinsic interest in selling hardware drives an inefficiency strategy, but most of us have no interest in higher hardware sells and more bandwith use, so lets start thinking about our practices.
Ok, if a company who has an intrinsic interest in selling hardware drives an inefficiency strategy, but most of us have no interest in higher hardware sells and more bandwith use, so lets start thinking about our practices.
I read a very interesting series of articles today I highly recommend: First comes from O'Reilly Radar from Steve Sounders asking: "How green is your webpage?". In that article he discusses some "simple" optimization techniques like putting proper expiry dates for images and analyses, that just this optimization could save six fully loaded web-servers for Wikipedia. O.k., not everyone is operating Wikipedia size, but there is a series of other optimisation efforts that can add to that bill. Yahoo Developer networks describes 14 best-practices for web-developers to get better performance for web-applications. Startin with "make fewer http requests" over "Expiry headers", proper usage of CSS and Javascript/Ajax.
The last resource I like to recommend (again? don't know, have a bad memory, sorry), is a talk from Rasmus Lerdorf on PHP, performance and profiling on conversations network. Btw. I think we should do more on profiling on this blog...
6 comments:
I couldn't resist blogging about your article: http://compaspascal.blogspot.com/2008/03/delphi-green-choice-for-environment.html
Thanks for this link; however, I must say, that I am not particularly convinced. By several reasons:
8 bit character sets are really a drawback; every software engineer knows the pain in the ass that encoding problems can produce. Unicode is really a significant step forward towards internationalisation.
Secondly, Delphi actually only runs on fat Windows PCs. This is not really the choice I would recommend.
The idea I would support is, to try to adjust the system to the actual need. It might be a mobile phone, that replaced (more efficiently) a Mac/PC for several scenarios, or a specialised Linux/BSD system that is focussed on a specific purpose without carrying all the fat parts of a Windows system.
Now I am not sure which impact the language has. This is however an interesting topic. We have seen, that modern VM can produce software with languages like Java or even .net that perform equally compared to Delphi or C++.
yet, I would say, that this question is not yet decided and would need more attention.
However, you make one important point: selling new machines is no green action. Green is to use available systems better, I completle agree on that.
Please note:
- 8-bit character sets in Delphi work fine with Chinese, Japanese, Arabic etc.
- Very few apps made on UTF-16 platforms support UTF-16 correctly.
- UTF-8 is my favorite choice, because it is very efficient in western languages.
- Other encodings than UTF-8 and UTF-16 may be most efficient with other languages.
- I don't care about character encodings, as long as the user is perfectly happy. I always consider the user more important than the technology.
I don't want to discuss the 8-bit character set issue too much, because my points was actually, that I don't believe it's helping the environment.
All discussions about programming techniques usually are about efficiency of one programmer. However, environment is about more than just programmers, and you need to discuss the programmer's position in society. Should the programmer spend time on improving an algorithm or on reducing the amount of fuel spent in world's transportion system?
Not all programmers are equally good, and some programmers can solve great problems, while others solve more trivial problems. If we want to improve on world environment, the correct question may be: What does it take for software for helping the environment more than damaging it, and how do we change society to help get more of that kind of software?
I don't believe that the solution is to make programmers focus on algorithms, platforms, design techniques etc., because it may remove focus from providing maximum value to the end-user, and eventually damaging that value.
Thank you for the clarification.
I try to get your point: you are right, that every individual, also a programmer or software architect, is facing a lot of choices in his or her life. This includes personal lifestyle and many other issues.
I also do not say, that efficient programming would safe the world.
Having said that, I do not believe either in silver bullets, and I believe, that we have to attack the problem on many levels. One level is to rethink our attitude to programming and software engineering. One.
Your argument that bad programmers probably are not able to focus on several aspects at the same time and in the end develop an efficient but useless program is generally a valid one.
Again, however: this is true for many aspects in software engineering. We also have to focus on algorithms, persistence, clustering, usability, accessibility and so on. Efficiency is just one more thing on the list, but an important one. One where developers can be trained, I believe.
Plus I also suggest that efforts in programming more efficiently have a series of positive side effects like: lower over-all costs by more efficient usage of available equipment, better knowledge on the runtime behaviour of a program (which also includes a better understanding of e.g. security issues, concurrency issues...) and much more.
Better understanding the actual behaviour of the software should also lead to better software with less issues.
very cool post
Unicode is not an encoding, it therefore does not make sense to say that it is 8 bit, 16 bit or 32 bit.
If you use unicode you only need change the encoding to one that is more efficient (after profiling). I have seen some results for xml/html that suggest that utf-8 is best even for Japanese and Korean. This would, probably, not be true for plain text.
Post a Comment