C++ vs C performance

Hi George,

Thanks for taking time and responding to my question.  I reviewed briefly those articles you sent me.  I was specifically interested in numbers rather than ideas how to program in C++.

What I would like to know is if anybody compiled a piece of code in C and C++ and compared the run time performance of the two.  I think it was common wisdom that C++ does not perform as C many years ago.  It depends on compiler if it has been improved in recent years.  So I am wondering how much slower is C++ compare to C.

regards,

If you compile a C program as C++ without changing the code, you'll usually get exactly the same performance.  There are a few corner cases where the C++ language is subtly different, but the typical program will not be affected.  Some C++ features such as virtual functions are indeed expensive to implement, giving C++ a reputation for being slower than C, but if you avoid those expensive features, C++ can be as efficient as C.

First of all, why are you concerned with performance? I am obsessed with performance on my core library, which has hardware abstraction and operating system built in.. All of the IRQ, task switching, timing stuff is in it. But on application side I don't care much. Actually using an operating system also helps, because low priority task is preempted by high priority tasks..

Performance became an issue only in rare projects, such as low processing power but high throughput. I accidentally had to compress/decompress audio on CC430, while communication with other peripherals were on going, data was received/transmitted through RF.. I had to tweak the compression section, and run a thread in background to catch up with incoming, outgoing data.. :) Apart from that singular problems, performance have not been an issue..

BTW, I saw guys who claim C++ bad at performance, while using floating point math to do simple stuff.. :)

Putting aside the "why", I usually do not like "do"s, and "don't"s.. I only care what works, and what does not, and say "be careful".. Sometimes one thing only creates problem, but sometimes it is the solution of another problem.. So, its up to you..

While C++ adds lots of useful staff, such as namespaces, templates, operator overloading, member hiding etc. etc. mainly C++ is actually C with compiler help.. It is basically help two ways:

1- Instead of writing doSomethingWith(object) in C, in C++ you write object.doSomething().. You do that in C alot. Call a function with an argument to work on. Behind the scene they are essentially same. Even the assembly out is the same.. Compiler does it for you.. But paradigm wise they are different. Writing object.doSomething() opens a lot of opportunities..

2- To differentiate wrt to objects, instead of creating a table of functions, and holding a pointer to table; you let compiler to do that.. Essentially only pro's create table of functions, novice programmers do it by switch clause, they even do not use sequential enumerations to cause compiler to generate jump tables..

So that's the major difference between C and C++.. I don't see any performance bottleneck here.. I've been programming in C++ nearly since I learned programming. At that time there was debate about performance but the problem was mostly in the paradigm, not the language..

Mostly string handling was the problem.. :) In C++, programmer uses a string class, which works with heap. For instance in one really bad implementation if you say s = s1 + s2; + operator generates space in heap, copies s1 and s2 to that, than = operator also creates  space in heap, copies result from + operator, than finally + operators copy is destroyed. 2 copies, 2 heap allocations, 1 heap deallocation..

A C coder usually allocates static memory for string, then writes: strcat(strcpy(s, s1), s2); this is just copy.. Although this is not optimized: strcat and strcpy returns not the end, but s itself and strcat has to search the the end. But it is not a big problem to write a simple copy and cat that returns the end of destination..

So, C++ implementation can not catch C equivalent.. Right? Not quite right.. The problem ıs the ugly implementation.. My implementation is building a tree of operators, and running that operator three when in the = operator..

Think about this:
StringBuffer<80> s;
s = s1 + (s2 + s3);

StringBuffer extends from String, with having 80 character buffer. No heap usage than.. (s2 + s3) creates StringStringAdditionOperator in stack that holds s2 and s3 as parameter in stack.  s1 + () creates StringOperatorAdditionOperator in stack that holds s1 and pre allocated operator.. So there is a tree.. Then = operator is fed with root StringOperator object. It calculates the position of each string and copies them to destination..

Of course because of StringOperator creation it is not efficient as strcat again.. (Actually it is more efficient as strcat searches end).. The problem with C++ is, you overload the operator but cannot tell the compiler to reverse the order.. If it allowed that, this could be much much more efficient.

But why not this:
s.copy(s1).append(s2).append(s3)?
Whala.. This is always optimized.. s.copy(s1) is called with s, but append's are diffferent.. s.copy copies s1 to s and returns StringAppender class which holds pointer s and to end of it, so each append is very efficient.. The beauty of this is the application developer does not have to think about performance each time, the library developer gives him efficient one.. Look at this, can you read what it does?

	// Date Time, YYYYMMDDHHMM
	UShort i;
	if (token.getNext().isNull() || (token.getLength() != 12)
			|| (token.getSubString(0, 4).toInteger(i) < 0))
		return ErrorInvalidFormat;
	DateTime dt;
	dt.setYear(i);
	if (token.getSubString(4, 2).toInteger(i) < 0)
		return ErrorInvalidFormat;
	dt.setMonth(i);
	if (token.getSubString(6, 2).toInteger(i) < 0)
		return ErrorInvalidFormat;
	dt.setDay(i);
	if (token.getSubString(8, 2).toInteger(i) < 0)
		return ErrorInvalidFormat;
	dt.setHour(i);
	if (token.getSubString(10, 2).toInteger(i) < 0)
		return ErrorInvalidFormat;
	dt.setMinute(i);
	dt.setSecond(0);

Could you imagine writing that one in C? The code does not copy anything, it just handles data in its place.. Would it be more efficient in C? I don't think so. And I am pretty sure C coder copies each part to buffer to work on it. Habit again.. :)

More importantly would it be easier to read?

Suggestions
- Careful with using exceptions. If it is not mandatory, avoid it..
- Careful adding a new virtual methods, if compiler sees a virtual it adds it even it is not reffered
- Try to handle data in its place. This is also valid for C..
- In C++ they say "don't use global variables". However, using global in MCU helps to reduce code also increases performance.. On call, compiler just assigns a constant to a register if the variable is global. If not, it reads the address of holding object, then it does a relative read to assign the address.
- If the performance is the issue, working with pointers in objects, try loading it to local parameter.. Compiler tends to read/write the same variable everytime.. This depends on optimization but I saw failures..

For instance, from my past trials:

void DoubleLinkedListBase::add(DoubleLinkItem* item)
{
	DoubleLinkItem* items = this->items;
	if (items == NULL)
	{
		item->next = item;
		item->previous = item;
		this->items = item;
	}
	else
	{
		DoubleLinkItem* p = items->previous;
		item->previous = p;
		item->next = items;
		p->next = item;
		items->previous = item;
	}	
}

This is also valid for C. I explicitly assigned this->items to items, and items->previous to p.. This was from one of my templates that is called frequently. If it were not the bottleneck, I would not care.. :)

I use fields without _ etc to differentiate. It gives me the power above. If I write items = this->items, now items are local.. I just be careful if arguments and local variables names are same with fields.. This method is like driving in bad road vs smooth road. You are become more careful when you use same name.. :) _ makes names cryptic.. Just suggestion, its up to you..

- Be careful with heap. C++ coders tend to use it frequently. Instead preallocate the space.. Actually C++ helps you on that with constructors. Constructor also means compiler will make you favor calling a predetermined method when you refer an object.. Even before main is run..

- This is not optimization but a pain reduction: If your globals are using each other, do not rely on compilers call sequence of constructors. Assume they are random..

Actually no switch change is required on TI's compiler. C++ is C with compiler help..