C Slower than Python?

[Bartc]

Bartc wrote, On 08/10/08 23:38:

Note that as has been pointed out you are calling strlen above so you
could actually use the correct values for whatever parameters are passed
in with no additional overhead.
?



Well, 1.8 seconds is less than 2 seconds. Note what I say above about
already having the correct numbers available programatically for the
memcpy calls.


Well, since less than 2 seconds is less than "nearer 2 seconds" and
significantly less than 2.5 seconds you have now shown that C is faster
than Python for this task if you write efficient C.

Only just, and by pretending that string lengths are available. Normally
they are not without extra effort.

But other posters have said their C code is quite a bit faster than Python,
by the sort of factors I would have expected.

 

[Flash Gordon]

Bartc wrote, On 09/10/08 00:24: ^^^^^^^^^ ^^^^^^^^^

?

Look at the bit of your code I have underlined above. The bit where you
find the lengths of the strings. That you don't keep the information as
was shown by a previous poster in this thread is your poor choice.

Only just, and by pretending that string lengths are available. Normally
they are not without extra effort.

Ah, but they *are* available. Try adding two extra variables to store
the lengths when you calculate them and then using those variables in
the two places where you need the length.

But other posters have said their C code is quite a bit faster than
Python, by the sort of factors I would have expected.

Try turning your optimiser up!

 

[Flash Gordon]

Richard Harter wrote, On 09/10/08 01:18:

<snip>

Many thanks for rooting through the code.

It's one of the things the group is here from

Well, no, I meant 0. I never use NULL. The only reason it is in
the code is that I copied the first few lines of the original.

OK, I can live with either as long as it is consistent.

Appropriate, perhaps, but size_t for indexing through an object
is always right.

Well, in this case the iteration is longer than size_t is guaranteed to
allow.

I do. I hardly ever use clock so I looked it up. I misread the
standard.

Easily done.

Generally speaking, it is a bug, but in this program it is not -
malloc is called exactly once. That said, the code should have a
free.

True. I was forgetting the length does not change and thinking about the
general principle. I've written code for ever-increasing buffers so
often it was automatic.

strcpy(a,b);
strcpy(a+len_b,c);

How about...
memcpy(a,b,len_b);
memcpy(a+len_b,c,len_c+1);
Alternatively loose the +1 and add a[len_a]='\0';

Good catch. That should be faster.

I've written mystrdup a implementation and thought very carefully about
it because it was likely to be called a lot of times. Same principle. Of
course, there is no guarantee of it being faster, we just both expect it
to be

<snip>

 

[Richard Bos]

However, this code doesn't realistically emulate the short string handling I
was trying to test; in practice each string will have a different length,
and the destination may already have content that needs to be cleared.

Then ISTM that your original benchmark wasn't greatly to the point,
because it didn't take any of that into account, either.

Richard

 

[Dik T. Winter]

> Dik T. Winter wrote:
> ) The difference in time is almost certainly because Python keeps track of
> ) the length of strings, which C does not. And moreover, Python uses
> ) problably a special memory allocator.
>
> I disagree.
> The difference is almost certainly because of the memory allocator.
>
> Keeping track of the length of the string has a negligible effect on such
> small strings.

All operations are on small strings. But I did measure and I found a 25%
different when removing strlen and kept track of the length of the strings
in another way.

 

[Dik T. Winter]

> news:[email protected]... ....
>
> Only just, and by pretending that string lengths are available. Normally
> they are not without extra effort.

In Python the string lengths are always available without effort, that is
by design. You can do the same in C if you design your program properly
but in that case the language will nog help you.

 

[MisterE]

OK, this code is naive and simplistic, but how else would you do it in C?

(BTW I've omitted malloc checking, which is in my own code and I presume
is
in Python.)

Why are you malloc'ing. You might as well compare apples to oranges. Without
the mallocing the program runs waaaaaaaaaaaaay faster.