for(; iter != endIter; ++iter)
{
//do something simple
}
// VS
for(; iter.compareTo(endIter) != 0; iter.next())
{
//do something simple
}
[.net] operators hughe performance impact!
Author
Wow, I just played around some with c# and created a custom container implemented with as an array.
And since I'm a big fan of old c++, I made my collection ala std::iterator style.
After some performance testing, I found that iterators using overloaded operators iterating over my collection, was approximately 4 times slower than exactly the same operation using normal functions instead of the overloaded operators:
from:
iter++;
to:
iter.next();
The code looks like the following:
To me it's strange that the difference is that big? Why not just make the compiler rewrite the overloaded operators to equivalent functions instead?
Maybe I'm totally off here?
Hi FxMazter, are you sure it isn't the 'iter.compareTo(endIter) != 0' section that is slowing it down?
Author
Hum, I don't think you got it right, I mean't that the second version with the iter.compareTo() and iter.next() was a lot faster than the version with the overloaded operators, even though the operators and the functions do exactly the same thing.
Oh, btw, maybe It's not so obvious that "iter" and "endIter" is a custom class with overloaded operators for != and ++.
Oh, btw, maybe It's not so obvious that "iter" and "endIter" is a custom class with overloaded operators for != and ++.
How are those functions implemented? Chances are, iter++ and iter.next() perform two completely different things.
CM
CM
Author
They are exactly the same, since I made them both for testing I have made sure they do exactly the same stuff.
Author
Oh dang, I'm terribly sorry everyone!
Stupid me measured performance with debug settings, in release settings both versions ran with the same speed.
Really sorry to have caused any confusion :(
Stupid me measured performance with debug settings, in release settings both versions ran with the same speed.
Really sorry to have caused any confusion :(
Also, you're carrying over a horrible feature from the STL: The need for custom iterators.
If you implement the IEnumerable interface on your collection, you can use the foreach() statement, which is so much more readable and easier to use.
I prefer
foreach (Object o in MyCustomCollection)
{
}
over
for (; iter != myCustomCollection.End; ++iter)
anyday [grin]
Toolmaker
If you implement the IEnumerable interface on your collection, you can use the foreach() statement, which is so much more readable and easier to use.
I prefer
foreach (Object o in MyCustomCollection)
{
}
over
for (; iter != myCustomCollection.End; ++iter)
anyday [grin]
Toolmaker
Quote:Original post by Toolmaker
Also, you're carrying over a horrible feature from the STL: The need for custom iterators.
If you implement the IEnumerable interface on your collection, you can use the foreach() statement, which is so much more readable and easier to use.
I prefer
foreach (Object o in MyCustomCollection)
{
}
over
for (; iter != myCustomCollection.End; ++iter)
anyday [grin]
Toolmaker
That works great if you're trying to print the contents of your collection. It works considerably less well if you're trying to modify them.
In my own container implementation, I provide both, plus a wrapper class that converts an iterator range into an enumeration. The wrapper class's syntax is still rather ugly, though, since the compiler is unable to figure out the types on its own.
*edit: Insert disclaimer about not reinventing the wheel here.
CM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
