optimizing my code (memory usage, postfix and prefix notation, "continue")

Started by
11 comments, last by Ravyne 11 years ago

Hello all

I don't usually write posts here, as I can find most information in the books I have, but I really have an interesting question here.
I read some info on sequence points and order of evaluation in C++, but I'm still not sure about this issue.

I have the following code (tiny part of a bigger function ofcourse).


line is a string, ll is an int, j is an int and splitchar is a char
The object of this piece of code is to increase j by 1, as long as the characer of line with index j, equals splitchar.
The character of line with index j, before execution of the inner while loop code, always equals splitchar, quaranteed. So j will be increased by at least one.


//some code
int ll = line.length();
int  j(0);
while(j < ll)
{
//some code that uses and changes j, but nothing very important. It doesn't influence the following code or the subject of this topic.
while (j < ll - 1 && line[j] == splitchar)
++j;
//some code
}

I changed the inner while loop to


while (j++ < ll - 1 && line[j] == splitchar)
continue;

or


while (j < ll - 1 && line[++j] == splitchar)
continue; 

which are pretty much the same. Trust me, I've tested everything in detail ;)
Note: postfix or prefix notation is very important here!

Now, my questions are;

1. Does it matter if I write "continue", or empty braces ("{}") in the last two examples, and how does this affect the performance?
2. Which one of these three would have the best performance?

3. Is there an even better possibility?

Performance is not very important in this program, but I really want to know the little details, because it WILL matter in future projects.
Thanks in advance smile.png

Nick

Advertisement
Edit: Ignore this post, I didn't think it through properly and SiScrane already corrected me.




while (j++ < ll - 1 && line[j] == splitchar)
continue;
or



while (j < ll - 1 && line[++j] == splitchar)
continue;


Both versions are not well-defined C++. The value of j is undefined (see this Wikipedia page). A colleague of mine recently ran into problems because they were working on code that relied on that but then had to change compiler version.
&& is a sequence point in C++. j is only accessed once on each side of the && in both versions so this looks well defined. Nonetheless, I would avoid loop conditions with side effects.

Also, I would avoid variables that only include the letter lower case l. It's too easy to mistake l for 1 in many fonts used in programming.
Really? Well, you keep learning. Still, I would agree with SiCrane and avoid the loops even if they are well defined.

Performance is not very important in this program, but I really want to know the little details, because it WILL matter in future projects.

It really won't.

Write all 3 versions of the loop, compile it with all optimisations turned on, and look at the resulting assembly. Even money says they all generate the same assembly.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

Oh those quirky optimization attempts could well go wrong cause it can be undefined behavior when the increment of a variable thats used twice inside a statement happens. The last is always different from the original as j would be increased before accessing the array, which it was not in the original.

Also abusing the continue statement in this way when there is no jump needed looks ugly and a few years ago some compilers without good optimization could even have added a useless jump instruction.

Edit: slight clarification for language lawyers

Nick C., on 27 Mar 2013 - 07:54, said:


Performance is not very important in this program, but I really want to know the little details, because it WILL matter in future projects.

It really won't.

QFE. It won't.

It'd be better

to use the std:string member function find_first_of like so:

[source='cpp']size_t pos = line.find_first_of(splitchar);

if(pos != string::npos)
{
//do your stuff here.
}[/source]

Err. Sorry, reading comprehension fail. Nonetheless the above is good advice for finding the first occurence of splitchar that I'll build on in a bit, so I'll leave it be.

It'd be better[really, this time] to use the std:string member function find_first_not_of like so (if you know that line begins with splitchar):

[source='cpp']size_t pos = line.find_first_not_of(splitchar);

if(pos != string::npos)
{
//do your stuff here.
}[/source]

If you don't know that line begins with splitchar, then you can combine these two member functions like so:

[source='cpp']size_t pos = line.find_first_not_of(splitchar, line.find_first_of(splitchar));

if(pos != string::npos)
{
//do your stuff here.
}[/source]

throw table_exception("(? ???)? ? ???");


while (j < ll - 1 && line[j] == splitchar)
++j;



while (j < ll - 1 && line[++j] == splitchar)
continue; 

Even though I got -2 for pointing out how this is a failed optimization attempt, that code is not equivalent and you should stop trying to microoptimize such irrelevant things when you are likely to introduce bugs.

Even though I got -2 for pointing out how this is a failed optimization attempt, that code is not equivalent and you should stop trying to microoptimize such irrelevant things when you are likely to introduce bugs.

I don't think you were downvoted for suggesting the optimization was useless and an irrelevant micro optimization. You were downvoted because you said it's invoking undefined behavior. It is well defined. I made the same mistake because I didn't think it through properly more than four hours before you though and I was already corrected.

Also abusing the continue statement in this way when there is no jump needed looks ugly and a few years ago some compilers without good optimization could even have added a useless jump instruction.

Its hardly abusing continue. The fact that a compiler might have mishandled it in the past is not an indication of some terrible practice going on. It's probably good to avoid using looping structures solely for side-effects, as someone else pointed out, and there are better tools as I pointed out myself, but if you did it anyways, using continue is probably a better option than empty braces or a semicolon. At least it stands out and says precisely what the intent was. Empty braces might invite the thought that the programmer forgot to fill in the loop body, and an empty statement (a single semicolon) is first of all very easy to miss, and causes really strange errors if you should ever forget or mistakenly delete it.

throw table_exception("(? ???)? ? ???");

This topic is closed to new replies.

Advertisement