What is the difference: Calling a (c based) program OR inline c code

[baurel]

hi
Suppose I would like to improve the performance of a Perl program with the help of C. Is it correct, that I basically have the following two options:
1.) to call external (C based) programs from perl (with backticks, system(), open(), ...).
2.) to extend Perl with C (XS, Inline::C, ...).
I think approach 1.) is much more simpler. Could somebody maybe explain me the differences between these two solutions? Is there a threading problem if I call external programs? Is there less scaling capacity? Why going the hard way with extending Perl? Sorry for the bad english...
ben

[JavaFan]

The big difference is that if you call an external program, it's a different program. It's completely separate. If it crashes, your main program still runs. If it uses a lot of memory, the memory is released when the external program exits.

If you extend Perl, you can do a lot more. You can peek inside Perl variables - even change them directly. You can walk the OP tree. And many more things.

It'll depends on the specifics of the problem you want to solve what your best action is. There's no general rule.

[Illuminatus]

As has been implied, without more information, it is hard to recommend one over the other. I can think of only 3 reasons to integrate perl with C (or any other language):
1. The function you want to use is complicated, and has already been implemented in another language/environment
2. The function you want is computationally intensive, and can written to run significantly more efficiently in another language/environment
3. The function you want is memory intensive, and memory usage can be managed significantly more efficiently in another language/environment
The performance difference is process startup overhead vs function call overhead. On Linux (2.6, current pentium chip), process startup is generally 2-3 ms tops. A function call is about 1 us tops. How often you call it, and how long it takes to run per call, will determine how important overhead ends up being.

Taking advantage of an SMP environment is a design issue. Just because you split something into threads/processes does not mean it will run any faster

[jethro]

An important difference is that you have all the operating system overhead of calling a second program and transfering data to it. If your external program has a big enough task to do and the data you have to exchange between your script and the c program is not too big, that works well. But if you want to speedup some small calculation that is performed a thousand times in your script you will likely make it slower

[evaluator]

If you are on Windows, you also have

3) Write a DLL, and use it through Win32::OLE

[BrowserUk]

and use it through Win32::OLE

That would be an ass-back'ards way of doing things.

1. Inline::C creates a dll from the C code and puts the glue in place to load and call it.
2. You can access the functions in any DLL via Win32::API.

Using Win32::OLE is about more black magic than just about any other module. Jumping through the hoops required to create an OLE callable DLL--just so you can access it via that module--is really seeking out the path of most resistance.