Basically, my argument is this: Some language features can be avoided, but functions are not one of those features. Some implementation deficiencies can be worked around, but if function calls are too slow, there is no workaround. Every nontrivial program must contain lots of function calls. So if Perl's function calls are "too slow" (whatever that means, and nobody in this thread has suggested any relevant meaning) then you have only two choices. One is to fix Perl. The other, as you said, is to be a problem-solving engineer, to recognize that you are in a hopeless situation, and to obtain a tool that is not hopelessly defective.Maybe I'm not reading that right, but that sounds like a huge failure of imagination. Here's my recipe for writing programs. First, you should try make sure you're using a low complexity algorithm if there's one available (i.e. no exponentials or O(n**2), O(n**3), etc.). Then you code up the problem in a functional manner, in high level language like Perl. The test and debug it on small amounts of data. Then you try running it. If its not fast enough, profile it to identify the "inner loop", which might only be 5% of your code. If the "inner loop" is a recursive function, rewrite it in tail recursive form (using a manual stack if necessary) and implement it with a while loop, eliminating the function calls. Or maybe the problem calls for some manual inlining (also called fusion or deforestation). If its still not fast enough, write the inner loop in C. If that's not fast enough, then you need a faster machine. But in any case, you've still got the (debugged, tested) Perl version to test your other programs against. Here's some fine further reading to keep you motivated.
In reply to Re^4: Performance, Abstraction and HOP
by Anonymous Monk
in thread Performance, Abstraction and HOP
by pg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |