|There's more than one way to do things|
Re^2: Why is Apache::File 'twice as fast' as IO::File ?by adrianh (Chancellor)
|on Jun 26, 2003 at 12:58 UTC||Need Help??|
Probably because the guys and gals at Apache recognise the importance of performance, and take the time to optimise their code.
Nope. It's because the Apache::File module is aimed at a specific task and IO::File is part of a generic IO system. Apache::File is faster because it doesn't do all the things that IO::File does.
As distinct from the wider perl community, if most of those around this site are anything to go by, who don't bother to. After all, "hardware is cheap!".
That's not been my experience. Can you give some examples?
(And the mod_perl folk are a big part of the perl community :-)
They don't seem to realise the damage it causes to the Perl's reputation when potential commercials users put together a POC using half a dozen CPAN modules, each of which is profligate with both time and memory, and run it along side a similar app written in Java, and waddaya know. The perl app runs 10 times slower.
Again, that's not been my experience. Usually I find that Perl and Java applications are well within an order of magnitude of each other speed wise. Sometimes Java is faster. Sometimes Perl is faster. The difference is usually not enough to sweat about.
In fact it's more common for me to find that I have to throw more hardware at Java applications because of the overhead of J2EE et al.
Can you point us to some commonly used CPAN modules that you think are particularly poor performance wise?
Yes, there are always some instances where language X is going to be faster than language Y for some task. However, in the domain I spend a lot of time (web applications and data munging) they both seem to perform equally well.
In my experience those potential commercial users are more impressed by the fact that they're playing with the Perl proof of concept three weeks before the Java one is finished :-)
Ah, but the culprits are the layers of standard and cpan modules that we cannot modify because its standard co. policy not to modify 3rd party software.
Because a company has a foolish policy this is Perl's fault how?
Most modules are licensed so that you can take them and change them as you want. You can just fork a new version if you need more performance. Since perl is dynamically typed you can write your "efficient" object with the same API and have it play happily with the rest of the application.
Java's not exactly been free of poor package implementations either has it? And you don't have the source available to fix them ;-)