[XPOST] [C] Access speed: pointers Vs array

[Il Prof]

[xpost and followup-to: comp.os.linux.development.apps]

Hi to everyone!

In C language on Linux, what string access method is faster?

1) Puntatori
char str[]="hello";
char* pstr;
pstr = str;
// access such as "*pstr"

2) Array
char str[]="hello";
// access such as "str"

To answer this question, and inspired by
simple!) code [1] that calculates the string access time based on the
previous two methods (in different implemented versions of strcpy).

My platform was:
- gcc compiler
- Kernel linux 2.4
- Knoppix 3.2
- Hardware intel Pentium 4 M 1.8 Ghz, 256 MB RAM

RESULT: the array access method seems faster!

What are your comments?


[1]CODE
#include <stdio.h>
#include <string.h>
#include <time.h>

strcopy1(char s1[],char s2[])
{
int x;
for (x=0; x<=strlen(s2); x++)
{
s1[x]=s2[x];
}
}

strcopy2(char s1[],char s2[])
{
int x;
int y = strlen(s2);
for (x=0; x<=y; x++)
s1[x]=s2[x];
}

strcopy3(char s1[],char s2[])
{
int x;
int y = strlen(s2);
for (x=0; s2[x]==0; x++)
s1[x]=s2[x];
}

strcopy4(char* s1, char* s2)
{
while(*s2 != '\0')
{
*s1 = *s2;
s1++;
s2++;
}
}

strcopy5(char* s1, char* s2)
{
while(*s2)
*s1++=*s2++;
}

strcopy6(char* s1, char* s2)
{
while(*s1++=*s2++);
}


main(int argc, char *argv[])
{

double interval;
time_t start;
time_t finish;
char* pstring1;
char* pstring2;
long int i = 1;
const int bound = 10000000;


char string2[] = "I'm testing the speed of execution of strcpy. I'm
testing the speed of execution of strcpy. I'm testing the speed of
execution of strcpy.";
char string1[200];

pstring1 = string1;
pstring2 = string2;


//STRCOPY1
time(&start);
while (i<bound)
{
strcopy1(string1,string2);
i++;
}
time(&finish);

interval = difftime(finish,start);
printf("\n");
printf("STRCPY1: ");
printf("%f", interval);
printf("\n");

string1[0]='\0';
i=1;

//STRCOPY2
time(&start);
while (i<bound)
{
strcopy2(string1,string2);
i++;
}
time(&finish);

interval = difftime(finish,start);
printf("\n");
printf("STRCPY2: ");
printf("%f", interval);
printf("\n");

string1[0]='\0';
i=1;

//STRCOPY3
time(&start);
while (i<bound)
{
strcopy3(string1,string2);
i++;
}
time(&finish);

interval = difftime(finish,start);
printf("\n");
printf("STRCPY3: ");
printf("%f", interval);
printf("\n");

string1[0]='\0';
i=1;

//STRCOPY4
time(&start);
while (i<bound)
{
strcopy4(pstring1,pstring2);
i++;
}
time(&finish);

interval = difftime(finish,start);
printf("\n");
printf("STRCPY4: ");
printf("%f", interval);
printf("\n");

string1[0]='\0';
i=1;

//STRCOPY5
time(&start);
while (i<bound)
{
strcopy5(pstring1,pstring2);
i++;
}
time(&finish);

interval = difftime(finish,start);
printf("\n");
printf("STRCPY5: ");
printf("%f", interval);
printf("\n");

string1[0]='\0';
i=1;

//STRCOPY6
time(&start);
while (i<bound)
{
strcopy6(pstring1,pstring2);
i++;
}
time(&finish);

interval = difftime(finish,start);
printf("\n");
printf("STRCPY6: ");
printf("%f", interval);
printf("\n");;

string1[0]='\0';
i=1;

//STRCOPY7
time(&start);
while (i<bound)
{
strcpy(pstring1,pstring2);
i++;
}
time(&finish);

interval = difftime(finish,start);
printf("\n");
printf("STRCPY7: ");
printf("%f", interval);
printf("\n");;

string1[0]='\0';
i=1;

}
OUTPUT
TIME(in seconds):
STRCPY1: 531.000000
STRCPY2: 12.000000
STRCPY3: 4.000000
STRCPY4: 7.000000
STRCPY5: 6.000000
STRCPY6: 10.000000
STRCPY7: 3.000000

 

[Jack Klein]

[xpost and followup-to: comp.os.linux.development.apps]

*plonk* for rudeness.

Who are you to decide that posters in comp.lang.c are entitled to
answer your questions and not even see their own posts, especially if
they don't notice that you trimmed comp.lang.c from the follow-ups?

Your question is off-topic anyway. The C language doesn't define the
relative speed of *ANYTHING*, and it doesn't define Linux at all.
This is not a language question, it is a gcc compiler implementation
question.

 

[CBFalconer]

[xpost and followup-to: comp.os.linux.development.apps]

*plonk* for rudeness.

Who are you to decide that posters in comp.lang.c are entitled to
answer your questions and not even see their own posts, especially if
they don't notice that you trimmed comp.lang.c from the follow-ups?

I disagree. He even announced the follow-ups, and I consider that
having the original poster set follow-ups to one newsgroup goes a
long way towards killing these long off-topic threads. In fact I
applaud his action there.

Your question is off-topic anyway. The C language doesn't define
the relative speed of *ANYTHING*, and it doesn't define Linux at
all. This is not a language question, it is a gcc compiler
implementation question.

And I agree here. This should never have appeared on c.l.c in the
first place.

 

[Il Prof]

[xpost and followup-to: comp.os.linux.development.apps]

*plonk* for rudeness.

Also you can't read my message...

Who are you to decide that posters in comp.lang.c are entitled to
answer your questions and not even see their own posts, especially if
they don't notice that you trimmed comp.lang.c from the follow-ups?

There was, as netiquette docet, the xpost&f/up warning.

Your question is off-topic anyway.

Sorry, i will not post other messages on this topics here.

Regards.

 

[David Schwartz]

Your question is off-topic anyway. The C language doesn't define the
relative speed of *ANYTHING*, and it doesn't define Linux at all.

There are certainly C-language aspects to his question. For example, the
standard may permit certain assumptions on arrays that it doesn't permit on
pointers. As a simple example, two arrays can often be assumed not to
overlap in situations where two pointers couldn't.

This is not a language question, it is a gcc compiler implementation
question.

Where compiler implementation questions come down to what the standard
allows and what it doesn't, they are also C language questions. The question
asked is sufficiently broad that it could be answered from many different
points of views and persectives.

I give the OP the benefit of the doubt and suspect he added comp.lang.c
because he also wanted an answer from a C standard perspective. You notice
that neither Linux nor gcc were present in his choice of the subject line,
and many of his issues (bugs in the implementations, cases where the
standard required multiple function calls versus cases where it didn't)
could be addressed from a pure C language perspective.

After all, the next version of gcc may be implemented very differently,
but the C standard is not going to change.

DS