Thread: c++ time saving techniques

What sort of "timesaving" are you after?
- Shorter execution time
- Shorter time to produce the code
- Less maintenance in the long run

Or something else?

--
Mats

I've always thought that the "Not Preferred" way is actually more idiomatic. Anyway, those couple of microseconds you might (or might not) gain wouldn't make any noticeable difference in a large majority of loops of the program. (In your example it seems to mask the small error that you have chosen an unsuitable type for storing the size - size_t should be more proper . In the "Not Preferred" version you'd be warned about that by the compiler.)

Not so much with functions that are known to be expensive, such as strlen, though.

I was going to post a link, but your bolded quote appears to come from that.

In general, I guess, worry less about small inefficiencies (only if they actually cause performance problems). Does it make you happy if program output rushes by 10% faster, if you are not going to be able to read it one way or another (and if nobody is going to read it, why not omit output altogether and gain a major speed boost)? (Concerning the ease of reading format strings, you might look into boost::format which combines the benefits of readable format string with type checking - but it might be slower than both alternatives.)

Originally Posted by gvkalra

what am currently doing is researching on all the techniques that one would have ignored if not known ....... e.g.

C++ stream I/O is a very flexible and safe method of doing input and output. It allows you to define specific output formats for your own objects. If an object doesn't support output, the compiler will tell you. Our old friend printf, on the other hand, is not very safe. If you specify the wrong number of parameters, or give the wrong order, you crash. You can't define new output formats, either. But printf does have a few things going for it: it's fast, it's easy to use, and it's often easier to read than long lines of << operators


At this point I am trying to open up in all the directions, be them compiler based or user based.....
one more example:
Try avoiding function call at the for loop condition check

for ( ninitialize = 0 ; ninitialize < vec_nVal.size() ; i++ ) //Not Preferred

int nVecSize = vec_nVal.size(); //Preffered
for ( ninitialize = 0 ; ninitialize < nVecSize ; i++ )

..........

I hope I have made myself clear..... What I want to do is teach some general time saving techniques to students that they might not be aware of.......

As anon points out, calling vec_nVal.size() in the loop is probably not too bad. It is much worse to call for example strlen() or the size of a linked list (if the list doesn't keep a count of how many items there are in the list, that is). And it may well be that if size is an inline function, there is very little, if any, difference between the "call size" and "use an extra variable".

--
Mats

I suppose that while shifting that function call has minimal impact, there might be some gain, and it costs very little to implement, so perhaps it can be classified as a "don't pessimise prematurely" optimisation. More obvious examples would include using the prefix form of operator++ and operator-- for iterators, and passing expensive to copy objects by const reference instead of by value (unless a copy will be done anyway).

The use of generic algorithms can also ease the use of these three "techniques" altogether since you would not manually perform the loop condition test and increment/decrement, and since you pass a range with cheap to copy iterators, you would not be passing a container by value.

Make sure you learn and use RAII, and idioms such as copy and swap.