why embed C into Perl

chuckd has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: why embed C into Perl by jethro (Monsignor) on Aug 03, 2008 at 22:37 UTC
The appropriate time is after you've done some profiling. Only when you have identified a (separable) routine or part of your program that takes up a big chunk of the runtime (and isn't just slow because of I/O) is it worth thinking about using C. If a hash could be done faster in C then the perl interpreter would already do that. Don't try to make perls data structures faster, think about making parts of your code faster. If you think about speeding up data structures you also have to think about whether you still have anything left from the speedup after the data was translated from perl to C and back again. Lets say, you find a subroutine in your code that uses up 20% of your runtime. And you speed that up a hundred times faster, which would be a phenomenal "get out the champagne" success. But your overall speed up would still only be less than 20%. That is 8 minutes instead of 10. You see, you really need to find something that takes up a major part of your runtime or you will be just wasting your own time	[reply]
Re: why embed C into Perl by shmem (Chancellor) on Aug 03, 2008 at 22:37 UTC
so what would be the best utilization for speed with C embedded in Perl? Roughly - any time you have to perform expensive operations on data of a known type. Perl's data types (scalars, arrays, hashes) are, at the C level, data structures with a copious amount of flags and magic stuff dangling; using embedded C you avoid shuffling around that in the algorithm you want to implement. Input and output still have to be perl variables. --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply]
Re: why embed C into Perl by Perlbotics (Archbishop) on Aug 03, 2008 at 22:48 UTC
For me, the most appropriate time to embed C code into Perl is to benefit from a probably extensive C code library by making it available to Perl programs. Especially if the C library allows access to resources close to the operating system, like i.e. for GUI programming (Wx). Taking advantage of CPU specific features like SSE might be another example. As always with optimisation, it depends on the circumstances - speed is often at the opposite end of generality. Hashing might be faster in C for data that has very specific characteristics, but my gut feeling is that for general purpose applications, it isn't worth the effort to compete with Perls hash implementation. Same with (generally speaking) looping through arrays. Pseudo hashes might be faster already without struggeling the XPXS-interface (for Perl < 5.10 and by using fields)? Update: typos	[reply]
Re: why embed C into Perl by cdarke (Prior) on Aug 04, 2008 at 08:00 UTC
The main reason I embed C (actually, XS) is where an interface is available to C but not to Perl. This is particularly the case with operating system APIs. Sometimes Perl API wrappers are provided but might not offer the particular range of features needed, or be very awkward. For example, if I need to call a series of four or five APIs, passing values between them, it can be tedious and slow to convert values from C to Perl then back again (often using pack/unpack) - it makes sense to write all the calls in C and package it. These needs are specialised: you may well find that you do not have that need or that someone else has boldly gone before, and you can download the package from CPAN.	[reply]
Re: why embed C into Perl by ikegami (Patriarch) on Aug 03, 2008 at 22:07 UTC
Perl's hash implementation is already written in C, so that's a particularly poor example.	[reply]
Re: why embed C into Perl by dragonchild (Archbishop) on Aug 04, 2008 at 14:00 UTC
When things are too slow even after you have improved your algorithms, reduced your blocking on outside inputs, and profiled extensively. If you haven't done all three, then you shouldn't be looking at C. Yet. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]