On Sun, Aug 24, 2003 at 09:35:39AM +0200 Janek Schleicher wrote: > Pablo Fischer wrote at Sun, 24 Aug 2003 01:45:42 +0000:
> > Exists a website with benckmark running times in Perl? > > http://www.google.com/search?q=benchmark+perl+programming+languages Benchmark between languages are - at the best of times - misleading. They tend to contrive some seemingly common problems and compare their implementations in different languages. Not even the p5-porters have so far managed to come up with a reliable benchmark for comparing perl with perl (perlbench gives nice tables but real-world programs often seem to contradict these tables). But as it can be seen in this thread, the problem wont be solved using pure-Perl. Database access usually happens via modules written in C. Therefore, a program making heavy use of an SQL database written in pure C and one written in Perl will yield very comparable results. I remember the longest-repeated-substring problem that was discussed some months ago on MJD's quiz-of-the-week mailinglist. A reasonably fast Perl solution looked very un-Perlish (doing it all with raw index() and substr() operations for the sake of speed) and thus was easy to translate to XS. The C implementation was faster to an degree of 5%, at most. But sometimes it was even slower. On the other hand, Octave for instance was written in C and Fortran. If you take this and compare it with an implementation in Perl (if it existed), it will surely make Perl look very poor. So only for very sanitized ('pure') problems you'll be able to predice which implementation will likely be fastest. The problem of the OP is no such case. First you have the overhead of the FTP transaction, afterwards unzipping that can either be done the slow way (Archive::Zip) or in an intelligent way (when speed matters) through PerlIO::gzip or even an external unzipper. The only thing that really might make look one language more appropriate than the other is the sorting. But again, precise figures can't be given since Perl's sort is either very performant (when using one of the optimized default routines) or painfully slow (with a complicated custom comparison-routine). Then a little bit I/O is carried out. Again, only little significance to the language (they all are somewhat C-based). Yet, Perl is known to do I/O a little better than most competitors. Eventually, database-access. That's no concern when using one of the C-implementations in the DBD:: namespace. Conclusion: most common languages should be able to do that in reasonable time. They are no different than Perl in that they interface with C code for tasks like working with compressed files, I/O and databases. Unless of course you do in PROLOG or some other truely exotic language. Tassilo -- $_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({ pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#; $_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
