While I don't have quite the same case to relate, let me tell you about a daemon I wrote once. I worked with a company that used a java , web-faced system to track big lumps of data around the building (with versioning and various bells). This system become interactive enough that users could create a work order to copy chunk-of-data-BLAH from someplace to someOTHERplace.
I was tasked to write the poor little slave process to do the work orders. My initial try was with perl , it was quick, smart and IMO very cool. But it was deemed that rather than a CGI perl service, this was to be done using Tomcat instead. Not knowing java , I ported the worker to python, then jythonized it to run with Tomcat.
The developer descends on me, howling about the slowness of this new service. Files were taking 10 times longer to transfer , no network or disk IO bottlenecks could be found. I went straight for the .py file , changed some shutil.copyfile()'s with actual system calls to cp and magically everything went a LOT faster , but still not as quick as perl.
I doubt this gives you much ammunition, but it's a Java vs perl story, where java won (but sucked) and perl lost (but got the job done). I am suspicious of other things pushing the bias toward java , certainly it was seen as more acceptable to use a python/java hack than a clever perl CGI. Why? I just dont know.
In reply to Re: Perl vs Java in Heavyweight Filesystem Processing
by submersible_toaster
in thread Perl vs Java in Heavyweight Filesystem Processing
by higle
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |