C++ is slow

[Charles Herman]

I have the following two programs:

PROG I
void main()
{
int *v = new int[NUM];
for (int i = 0; i < NUM; ++i)
v = i;
}

PROG II
class rvector
{
private:
int* vals;
size_t vsize;

public:
explicit rvector( size_t vSize ) { vals = new int[vsize]; }
~rvector() { delete [] vals; }

int& operator[] (size_t idx ) { return vals[idx]; }
};

void main()
{
rvector v(NUM);
for (i = 0; i < NUM; ++i)
v = i;
}

I left out some non-germane lines, eg, defining NUM and including header
files.

I compiled and ran these programs using VC++ 6.0. The second program
required approx 6 times as much time to run as the first. What is happening
in program II that takes so much time?

-charles

 

[Mike Wahler]

I have the following two programs:

PROG I
void main()

int main()

If you use anything else besides 'int' return type
for main, you have *no* guarantees about the behavior of
your program.

{
int *v = new int[NUM];
for (int i = 0; i < NUM; ++i)
v = i;

You have a memory leak. You need to free the memory
you allocate.

}

PROG II
class rvector
{
private:
int* vals;
size_t vsize;

public:
explicit rvector( size_t vSize ) { vals = new int[vsize]; }
~rvector() { delete [] vals; }

int& operator[] (size_t idx ) { return vals[idx]; }
};

void main()

And again.

{
rvector v(NUM);
for (i = 0; i < NUM; ++i)
v = i;
}

I left out some non-germane lines, eg, defining NUM and including header
files.

You should always strive to post *compilable* code if at all
possible. Then we needn't guess at the rest, which is often
the cause of a stated problem.

I compiled and ran these programs using VC++ 6.0. The second program
required approx 6 times as much time to run as the first. What is happening
in program II that takes so much time?

The C++ language is a set of specifications, an abstraction.
I has no 'speed', slow or fast. Apparently you find a particular
*implementation* of C++, (VC++6.0) "too slow".

Recommended actions:

Read your documentation to ensure you're using the product correctly,
and find it's various 'modes' of operation.

If VC++ is deemed unacceptable, use something else.

-Mike

 

[Mike Wahler]

I have the following two programs:

[snip]

{
int *v = new int[NUM];
for (int i = 0; i < NUM; ++i)
v = i;

[snip]

PROG II
class rvector
{
private:
int* vals;
size_t vsize;

public:
explicit rvector( size_t vSize ) { vals = new int[vsize]; }
~rvector() { delete [] vals; }

int& operator[] (size_t idx ) { return vals[idx]; }
};

[snip]

{
rvector v(NUM);
for (i = 0; i < NUM; ++i)
v = i;
}

You're comparing two different things, naturally their
behavior will often be different. Your 'rvector' class
does more work than your first example.

You're comparing "apples vs oranges".

-Mike

 

[Andrey Tarasevich]

...
I compiled and ran these programs using VC++ 6.0. The second program
required approx 6 times as much time to run as the first. What is happening
in program II that takes so much time?
...

Firstly, I compiled your program with VC6 and run it. Both cycles take
the same time to run, which is not surprising since both cycles are
compiled into identical code. You must be doing something incorrectly,
like testing debugging configuration of the code, which is meaningless.

Secondly, aside from some minor errors (like 'void main'), both programs
are valid C++ programs. Whatever the results are, this test cannot be
used to show that "C++ is slow".

 

[Leor Zolman]

I have the following two programs:

PROG I
void main()
{
int *v = new int[NUM];
for (int i = 0; i < NUM; ++i)
v = i;
}

PROG II
class rvector
{
private:
int* vals;
size_t vsize;

public:
explicit rvector( size_t vSize ) { vals = new int[vsize]; }

I'd look real hard at the spelling of those various version of vsize you
have there. What do you think the value of 'vsize' above really is? ;-)

[plus all of Mike's remarks]
-leor

~rvector() { delete [] vals; }

int& operator[] (size_t idx ) { return vals[idx]; }
};

void main()
{
rvector v(NUM);
for (i = 0; i < NUM; ++i)
v = i;
}

I left out some non-germane lines, eg, defining NUM and including header
files.

I compiled and ran these programs using VC++ 6.0. The second program
required approx 6 times as much time to run as the first. What is happening
in program II that takes so much time?

-charles

Leor Zolman
BD Software
(e-mail address removed)
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

 

[Aggro]

I have the following two programs:

PROG I
void main()

int main()

{
int *v = new int[NUM];
for (int i = 0; i < NUM; ++i)
v = i;

Did you forget something? delete [] v; perhaps? We don't want to cause
memory leaks, do we?

You will also want to put return 0; at the end of main, because VC 6.0
has a bug and it will complain about int main() if you don't use that. (
It is not required by the standard, but it doesn't matter if you use it.
I personally think that it is even better to use it. )

return 0;

}

PROG II

~rvector() { delete [] vals; }

Note that here you are using delete, unlike you did with the first
program. This might be causing some of the time difference.

int& operator[] (size_t idx ) { return vals[idx]; }
};

void main()

int main()

{
rvector v(NUM);
for (i = 0; i < NUM; ++i)
v = i;

return 0;

}

I left out some non-germane lines, eg, defining NUM and including header
files.

Don't do that they might contain some valuable information.

 

[Leor Zolman]

You're comparing two different things, naturally their
behavior will often be different. Your 'rvector' class
does more work than your first example.

You have no idea now /much/ more work... (sorry, Mike, couldn't resist)
-leor

You're comparing "apples vs oranges".

-Mike

Leor Zolman
BD Software
(e-mail address removed)
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

 

[Mike Wahler]

You have no idea now /much/ more work...

Um yes, I do. (or was that directed at OP?)

-Mike

 

[Rolf Magnus]

You're comparing "apples vs oranges".

http://www.inno-vet.com/articles/1999/0599/52.htm

 

[Mike Wahler]

http://www.inno-vet.com/articles/1999/0599/52.htm

In his experiment, he chemically and physically changes both
the apple and the orange. So he no longer has an apple or
an orange for comparison.

Also he's protesting that folks are using "apples vs organges"
to denigrate[sic] someone else's analogy. OP did not make an
analogy, I only used one to refute his complaint about
two *different* code examples.


-Mike

 

[Julie]

In his experiment, he chemically and physically changes both
the apple and the orange. So he no longer has an apple or
an orange for comparison.

In this case, simple dessication would not constitute a chemical change.

*Physical* comparison in the A vs. O anti-argument is expressly omitted, as the
physical characterists of apples and oranges are *very* similar at a macro
scale. Therefore, physical changes have no bearing on A vs. O.

 

[Julie]

I have the following two programs:

PROG I
void main()

int main()

If you use anything else besides 'int' return type
for main, you have *no* guarantees about the behavior of
your program.

{
int *v = new int[NUM];
for (int i = 0; i < NUM; ++i)
v = i;

You have a memory leak. You need to free the memory
you allocate.

}

PROG II
class rvector
{
private:
int* vals;
size_t vsize;

public:
explicit rvector( size_t vSize ) { vals = new int[vsize]; }
~rvector() { delete [] vals; }

int& operator[] (size_t idx ) { return vals[idx]; }
};

void main()

And again.

{
rvector v(NUM);
for (i = 0; i < NUM; ++i)
v = i;
}

I left out some non-germane lines, eg, defining NUM and including header
files.

You should always strive to post *compilable* code if at all
possible. Then we needn't guess at the rest, which is often
the cause of a stated problem.

I compiled and ran these programs using VC++ 6.0. The second program
required approx 6 times as much time to run as the first. What is happening
in program II that takes so much time?

The C++ language is a set of specifications, an abstraction.
I has no 'speed', slow or fast. Apparently you find a particular
*implementation* of C++, (VC++6.0) "too slow".

Recommended actions:

Read your documentation to ensure you're using the product correctly,
and find it's various 'modes' of operation.

If VC++ is deemed unacceptable, use something else.

-Mike

Crap. You answered anything but the OP's question.

void main, memory leaks, using different compilers, and diatribes about speed
in the standard don't do a thing for the OP and their perceived differences in
speed.

I think that Leor was the only one to infer as to the *real* problem here. I
didn't see the problem until he pointed it out.

Let's remember that this isn't
comp.lang.c++.lets.run.off.the.newbies.as.fast.as.possible.

 

[Alf P. Steinbach]

I have the following two programs:

PROG I
void main()

int main()

If you use anything else besides 'int' return type
for main, you have *no* guarantees about the behavior of
your program.

{
int *v = new int[NUM];
for (int i = 0; i < NUM; ++i)
v = i;

You have a memory leak. You need to free the memory
you allocate.

}

PROG II
class rvector
{
private:
int* vals;
size_t vsize;

public:
explicit rvector( size_t vSize ) { vals = new int[vsize]; }
~rvector() { delete [] vals; }

int& operator[] (size_t idx ) { return vals[idx]; }
};

void main()

And again.

{
rvector v(NUM);
for (i = 0; i < NUM; ++i)
v = i;
}

I left out some non-germane lines, eg, defining NUM and including header
files.

You should always strive to post *compilable* code if at all
possible. Then we needn't guess at the rest, which is often
the cause of a stated problem.

I compiled and ran these programs using VC++ 6.0. The second program
required approx 6 times as much time to run as the first. What is happening
in program II that takes so much time?

The C++ language is a set of specifications, an abstraction.
I has no 'speed', slow or fast. Apparently you find a particular
*implementation* of C++, (VC++6.0) "too slow".

Recommended actions:

Read your documentation to ensure you're using the product correctly,
and find it's various 'modes' of operation.

If VC++ is deemed unacceptable, use something else.

-Mike

Crap. You answered anything but the OP's question.

I think Mike can handle those expletives but.

He did answer all of the OP's questions, pluss pointed out the main flaws
in the code.

To reiterate, whatever happens in the second program that does not happen
in the first is not a language issue, but a question of what the author and
the C++ implementation puts in there (or rather, fails to optimize away).

And Mike pointed that you should always


first get the code _correct_.


If it doesn't need to be correct then I can show you a program that solves
the traveling salesman problem in 1 microsecond regardless of problem size.

void main, memory leaks, using different compilers, and diatribes about speed
in the standard don't do a thing for the OP and their perceived differences in
speed.

Possibly the answers do not enlighten you.

But see above.

If that does not help, then you need to study harder.

I think that Leor was the only one to infer as to the *real* problem here. I
didn't see the problem until he pointed it out.

Leor pointed out (and only pointed out) that you should always


first get the code _correct_.


Which Mike had already done.

It's difficult for me to see how Leor's answer could be perceived as any
"better" than Mike's much more comprehensive answer, but in spite of the
difficulties I think I've found an explanation: a large number of people
just want a cookbook recipe of WHAT TO DO to make something work for them,
immediately, disregarding what problems that might lead to for others.

Let's remember that this isn't
comp.lang.c++.lets.run.off.the.newbies.as.fast.as.possible.

It's got little to do with newbie status. Like "fourteen" is a state
of mind, not a physical age.

 

[Andrey Tarasevich]

...
I think that Leor was the only one to infer as to the *real* problem here. I
didn't see the problem until he pointed it out.
...

If you are referring to missing 'delete[]' in the first example, I find
it very unlikely to be the source of the problem. The OP probably
removed it by accident when he was preparing the code for posting (with
those "non-germane lines" he mentioned).

The OP's test code is located directly inside function 'main', not
inside some other function. If we assume that this is pretty much
exactly the same code he was trying to benchmark, it becomes clear that
in order to make the running time of the code measurable, he'd have to
use a rather large value of 'NUM'. But with large values of 'NUM' one
missing 'delete[]' cannot and will not result in 6x difference in
running time.

If the code were incapsulated into some other function (say, 'foo') then
it would be logical to suspect that for benchmarking purposes the OP was
trying to call 'foo' for some other cycle (which he didn't show us). In
that case he could use smaller values of 'NUM' and missing 'delete[]'
could contribute to a bigger difference in running time.

There's no way to tell what really happened without some extra
information from the OP, but the most likely reason with the available
code sample is that the OP was trying to benchmark a debugging version
of the code - a very common mistake among MSVC-using "C++ benchmarkers".

 

[Julie]

...
I think that Leor was the only one to infer as to the *real* problem here. I
didn't see the problem until he pointed it out.
...

If you are referring to missing 'delete[]' in the first example, I find
it very unlikely to be the source of the problem. The OP probably
removed it by accident when he was preparing the code for posting (with
those "non-germane lines" he mentioned).

Nope, the problem, as Leor pointed out, was due to the wrong variable being
used in the new allocation:

explicit rvector( size_t vSize ) { vals = new int[vsize]; }

I'd look real hard at the spelling of those various version of vsize you
have there. What do you think the value of 'vsize' above really is? ;-)

vsize is an uninitialized member variable, and *not* the vSize parameter that
was intended. Therefore, that random (and presumably large) sized allocation
is what is taking all the time in the OP's code, not anything to do w/ the
difference(s) w/ wrapping/accessing the array in a class.

 

[Leor Zolman]

Leor pointed out (and only pointed out) that you should always


first get the code _correct_.


Which Mike had already done.

It's difficult for me to see how Leor's answer could be perceived as any
"better" than Mike's much more comprehensive answer, but in spite of the
difficulties I think I've found an explanation: a large number of people
just want a cookbook recipe of WHAT TO DO to make something work for them,
immediately, disregarding what problems that might lead to for others.

There are lots of things the folks who answer questions here can do for the
posters of questions. ONE of them is point out the "showstopping" problem
that was most likely the major reason the post was made in the first place.
ANOTHER is to help the poster improve the general correctness of their
code, in terms of style and/or appropriateness to the problem at hand, plus
of course elimination of perhaps-less-showstopping but nevertheless serious
bugs. The latter piece is very important; folks like Mike bust their butts
to do such critiques, and everyone benefits from them. The OP's get better
code out of it, along with lots of ammunition to apply to every project
they embark on after that. Everyone else gets that ammunition too, if they
want it.

I tend to take the former approach a bit more often than, say, Mike does.
Often I get the gut feeling that, once the "showstopper" is gotten past,
the OP ought to be given the chance to evolve the code at his/her own pace.

In this case I had some confidence in Charles figuring out on his own that
C++ isn't "slow", that his constructor was flawed (beyond just the one
showstopping typo), and much of the rest. However, the decision on whether
or not to post more of a critique was spared me due to the fact that by the
time I had figured out about that typo, Mike had already posted his own
critique, thus saving me the trouble. If Mike's post hadn't made it
through yet at that point, I /might/ very well have continued on with more
comments... I guess we'll never know. But that's part of why my post was so
terse. There are dynamics here, and I think all of us play off each other,
complementing and reinforcing each other (and keeping each other honest.)

All anyone can do is take what they need from the often rich selection of
responses, and disregard whatever doesn't help.
-leor




Leor Zolman
BD Software
(e-mail address removed)
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

 

[Julie]

There are lots of things the folks who answer questions here can do for the
posters of questions. ONE of them is point out the "showstopping" problem
that was most likely the major reason the post was made in the first place.
ANOTHER is to help the poster improve the general correctness of their
code, in terms of style and/or appropriateness to the problem at hand, plus
of course elimination of perhaps-less-showstopping but nevertheless serious
bugs.

I don't disagree with that generally.

My problem is that it seems that there seems to be a lot more 'criticism' of
code, rather than answering the question.

I think that the tone of the forum would improve greatly, *especially* for new
posters and/or new C++ programmers *IF* we could first answer the question, and
then parenthetically offer the yards of critiques on correctness and
commentaries on style. I often wonder how many lurkers are out there,
absolutely terrified to ask any type of a question in fear that they will be
mercilessly ripped to shreds.

The way that I count it, your answer to the original question as to why "C++ is
slow" was the thirteenth response to the thread.

And I'm not ripping on anyone in particular. I include myself wholly in this.
*Every* single day, I reevaluate my tone, expertise or extreme lack thereof,
and general responses to newsgroup postings, and try to do a better job the
next day that *helps* those who post, newbie or seasoned expert.

Good bye.

 

[Nick Hounsome]

I have the following two programs:

PROG I
void main()
{
int *v = new int[NUM];
for (int i = 0; i < NUM; ++i)
v = i;
}

PROG II
class rvector
{
private:
int* vals;
size_t vsize;

public:
explicit rvector( size_t vSize ) { vals = new int[vsize]; }
~rvector() { delete [] vals; }

int& operator[] (size_t idx ) { return vals[idx]; }
};

void main()
{
rvector v(NUM);
for (i = 0; i < NUM; ++i)
v = i;
}

I left out some non-germane lines, eg, defining NUM and including header
files.

I compiled and ran these programs using VC++ 6.0. The second program
required approx 6 times as much time to run as the first. What is happening
in program II that takes so much time?

-charles

Did you compile this with debug?
If you do, most compilers will not inline and non-inlined STL is a
performance disaster.
The only other common performance **** up is if MS are dumb enough to try to
make
vector thread safe.
If it is inlined and not thread safe then even a beginner should be able to
lash up a vector
with no performance penalty.

 

[Stephen Gordon]

Leor Zolman wrote:
[SNIP]

I don't disagree with that generally.

My problem is that it seems that there seems to be a lot more 'criticism' of
code, rather than answering the question.

I think that the tone of the forum would improve greatly, *especially* for new
posters and/or new C++ programmers *IF* we could first answer the question, and
then parenthetically offer the yards of critiques on correctness and
commentaries on style. I often wonder how many lurkers are out there,
absolutely terrified to ask any type of a question in fear that they will be
mercilessly ripped to shreds.

Well I think it is important to provide critiques where possible, the fact
of the matter is that not everybody learning or using C++ is
University/College taught. If this is the case and someone here doesn't tell
them they are doing something that is generally not considered a best
solution then they might keep doing it ad nauseum not realising their
mistake. Also if people are learning C++ from scratch they should probably
be on alt.comp.lang.learn.c-c++

[SNIP]

Good bye.

Farewell

-Steve

 

[Leor Zolman]

My problem is that it seems that there seems to be a lot more 'criticism' of
code, rather than answering the question.

I think this is mostly due to the restrictions of the medium. I personally
don't feel I have the time to preface each critique with a disclaimer for
the poster "not to take this personally", or "Since it is easier for me to
make these comments in-situ, I'm going to critique your entire posting in
order (because that's the easiest, most efficient way for me to get through
it), but your "real problem" is somewhere there in the middle, and I'll
point it out en-passant"

Perhaps such a disclaimer ought to go into the FAQ (and not just for /this/
group).

I think that the tone of the forum would improve greatly, *especially* for new
posters and/or new C++ programmers *IF* we could first answer the question, and
then parenthetically offer the yards of critiques on correctness and
commentaries on style. I often wonder how many lurkers are out there,
absolutely terrified to ask any type of a question in fear that they will be
mercilessly ripped to shreds.

There's merit to this idea. Personally, I would have no qualms about
getting into the habit of putting an abbreviated version of that disclaimer
at the top; easier yet would be a one-line reference to a section of the
FAQ ;-)

The way that I count it, your answer to the original question as to why "C++ is
slow" was the thirteenth response to the thread.

As we say in amateur astronomy, this was a particularly "difficult object"
(to see, that is). The reason I figured it out "so fast" (and now I'm going
to be sabotaging whatever mystique I may or may not have built up as a
super-bug-detector) is because when I ran the longer version of the
program, it thrashed and thrashed /just/ like another program did a few
days ago when I purposely used umpity-million as the arg to new[] in order
to try and /purposely/ run it out of memory. So that pretty much led me by
the hand to the root of the problem. But then I had to go make an impetuous
remark in response to one of Mike's posts, and I wouldn't blame him at all
for being mad at me about it. Mike, I apologize for that.

And I'm not ripping on anyone in particular. I include myself wholly in this.
*Every* single day, I reevaluate my tone, expertise or extreme lack thereof,
and general responses to newsgroup postings, and try to do a better job the
next day that *helps* those who post, newbie or seasoned expert.

Amen. Case above in point.

Good bye.

Bye,
-leor

Leor Zolman
BD Software
(e-mail address removed)
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html