Developers and getting them to improve their code.

Zack Rusin kde-optimize@mail.kde.org
Wed, 8 Jan 2003 15:17:52 -0500


On Wednesday 08 January 2003 14:18, Benjamin Meyer wrote:
> A C++ optimization guide.  I have searched online and found many
> little one liner hints.  Some are obvious, but others aren't.  I
> really haven't found a common book/faq/website that has C++
> optimizations.  This should really get top priority for there are
> many C++ tricks that even old C++ developers don't know about and
> most new C++ developers have never even thought about. Putting
> together a comprehensive listing and asking for feedback from the
> community is a good project that would pay for itself many times
> over.

This depends on your school of thought I guess. The reason why : if 
you're not aware of basic language dependent optimizations then 
tutorial is not gonna cut it for you - you actually need a good book 
talking about the given language. If you think you need advanced 
optimizations ( architecture/compiler dependent, or things like version 
scripts) and you don't know them by hand then in 99% of cases these are 
not optimizations for you as your program/library is most probably 
lacking in other areas. 

What might be a good idea is a short faq about where to find what. Like: 
to learn about C++ specific optimizations we recommend the following 
books, websites.... for informations about version scripts read ld info 
manual... I think the actual documentation covering the topics is 
always better than a "developers cliff-notes".

> Along the same lines a tutorial for how to use valengrind would be
> good.

I'm not sure what would be needed in one, considering that valgrind has 
got great documentation. Maybe the only thing needed is how to be using 
it while working with nvidia glx drivers like I am.

> One of the things I have found is that many developers simply are not
> aware of a pre-existing class that already exists and implement 
> (poorly) themselves. Sometimes it is even such a simply thing as
> linked lists.  The best case of this is KConfig/QSetting/Config etc,
> the developer often re-implements this and later pulls it out.  Maybe
> creating some sort of program where developers can ask for peer
> review of the design of there application.

I'm not sure about that. I mean lets face very few of us would spend the 
time reviewing someone elses application. Especially, that in most 
case, the people requesting something like that would do it because 
they were too lazy to read the relevent documentation. 
If there's anything confusing people we should just add it to the 
developers faq.

> Code bloat. Between Qt and KDE there are a number of classes that do
> the same thing such as far as the developer is concerned.  (Such as
> QSocket/KSocket). These classes confuse developers for they don't
> know what to write for.  Even having them have the same api (minus
> class name) is a good start.  Combining these classes [with the help
> of TrollTech] would not only reduce binary size of the libraries it
> would free up developers who are doing duplication of work of
> enhancing these classes.

I'm not sure if we actually have any classes that are the same. KDE ones 
always contain something that's missing in the Qt version.

> I forget where I saw it, but there is a compiler that when compiling
> will spit out messages about code that is unessesary in release
> versions because they will bloat the binary's quite a bit.  ( Such as
> the assert() call ) so that developers can check to see if those
> calls are really needed and remove/change them.

I'm not sure I understand what you mean here.

Zack

-- 
Bill Gates: "Innovation"
Me: "You keep using that word, I do not think it means what you think
it means"