Re: Generally, are the programs written by C++ slower than written by
C 10% ?
On Sep 6, 3:51 am, Ian Collins <ian-n...@hotmail.com> wrote:
On 09/ 6/11 07:34 AM, BGB wrote:
On 9/5/2011 12:28 AM, Nick Keighley wrote:
On Sep 3, 9:45 am, BGB<cr88...@hotmail.com> wrote:
If I'm coding in C and I want to sort something. My first thought
would be qsort()! If it was too slow only then would I consider hand
coding it. Surely any constructively lazy person would use an existing
facility rather hand-roll their own!
different styles for different sorts...
actually, in my case I would probably far more likely copy-paste it and
then edit it to the new use.
copy-paste is a powerful tool which is often disparaged and overlooked.
Rightly so. C has things call functions that enable code to be reused
and C++ has function templates that remove the last excuse for copy and
paste.
but, one would typically write it themselves initially (before
subjecting it to endless copy-paste).
Not if they were being paid to deliver software.
it is also not clear that std::string would be, in general, faster, a=
nd
having an O(1) ability to fetch the length may turn out to be moot if
most other operations tend towards being more expensive.
are they?
from what I have seen, people tend to pass them around by-value.
Most C++ code passes strings by const reference.
apparently, the by-value vs by-reference thing makes a bit of a
difference WRT performance.
apparently, their performance characteristics also differ some between
GCC and MSVC, with the ones in MSVC apparently tending to be more expen=
sive.
granted, I haven't personally looked into all of this in-depth though.
With some compilers in some modes, passing a string by value will be
quicker if the string object (typically a pair of pointers) is small
enough to pass in registers.
there are also plenty of things often done with C strings as well that
can make them faster, such as interning them so that one can check
string equality using '==' on the pointers, rather than using
"!strcmp()", ...
In other words, wrapping them like std::string...
in my case, I tend to avoid "stdrup()" as well, as generally "strdup()"
is a good way to "make bad things happen" (slow, tears through huge
amounts of memory, leaves the program responsible to free them, ...), s=
o
preferable IMO is interning them into string-tables (a big glob of
memory where they are packed end-to-end).
then one can free the whole string table as part of a "teardown" proces=
s.
another strategy (used elsewhere) is to allocate the strings in the
garbage-collected heap (I use GC), and then manage them using a weak
hash (entries will be reset to NULL whenever any are reclaimed by the G=
C).
also, == and != work provided both strings are in the same string=
-table.
Or save a whole lot of pain and use std::string.
--
Ian Collins
My test code:
#include <iostream>
#include <string>
#include <cstring>
int main() {
clock_t tbeg;
{
tbeg = clock();
for (int i = 0; i < 10000000; i++)
std::string("hello, world!");
std::cout << "test 1 use " << clock() - tbeg <<
std::endl;
}
{
tbeg = clock();
for (int i = 0; i < 10000000; i++) {
char* str = new char[20];
strcpy(str, "hello, world!");
delete [] str;
}
std::cout << "test 2 use " << clock() - tbeg <<
std::endl;
}
{
tbeg = clock();
for (int i = 0; i < 10000000; i++) {
char* str = (char*)malloc(20);
strcpy(str, "hello, world!");
free(str);
}
std::cout << "test 3 use " << clock() - tbeg <<
std::endl;
}
{
tbeg = clock();
for (int i = 0; i < 10000000; i++) {
char str[20];
strcpy(str, "hello, world!");
}
std::cout << "test 4 use " << clock() - tbeg <<
std::endl;
}
return 0;
}
output:
----------------------------
test 1 use 1260000
test 2 use 850000
test 3 use 610000
test 4 use 20000
So, could I think that if an object is constructed and destructed
frequently, I should make its member data are POD (not std::string or
some other expensive thing) ? Like this:
class temp_cache1 {
private:
std::string s;
std::vector<int> v;
};
class temp_cache2 {
private:
char s[SIZE];
int v[SIZE];
};
Here, is temp_cache2 better than temp_cache1?
I use valgrind trace the test program, found that the std::string
will allocation memory from heap even if the string is very short,
like std::string("abc"), it will allocation memory from heap.
So, either use temp_cache2 or use temp_cache1 and don't let it
destructed,
reuse its s and v. Am I right?