rsFalse,

I suggest you do some benchmarks on what you want to do before declaring Perl to be "slow". I have some Perl "big-data" products that compete very well against similar "C" products. YMMV!

Many times is the mathematical algorithms/techniques/etc. that determines the final performance, and Perl is excellent at allowing you to quickly optimize.

I started out with similar views, but Perl won me over. You may be surprised at the performance of your well-designed "competitive programs".

Regards...Ed

I agree with this. I have rewritten several C programs in Perl over the last year and a half or so and succeeded to improve very significantly the performances. In part because Perl enabled me to use hashes, having much faster access than scanning sequentially a C array. Of course, if we had a C library offering a behavior similar to Perl's hashes, C would become better. But there no such library that we know of for our version of our OS, so that Perl is the clear winner (admittedly, we could write a fast look-up C library, using indexed array access or a hashing function, but, even assuming we could do that efficiently, that would be a lot of work for very limited benefit). And, at the end of the day, it takes us so much less time to write a Perl program than a C program that, if the Perl program gives enough performance, I don't even wans=t to consider the C alternative.

Having said that, there are of course some cases (e.g. heavy mathematical calculations) where C extensions (with Inline C, XS or some other mechanism) will bring a real advantage (in terms of costs and benefits analysis) over pure Perl. I haven't seen yet a case where this would be the case in our work environment.