[Jeff Epler] > I'd like to speak up about this patch I've submitted on sourceforge. I'm not sure that's allowed <wink>. > ... > The point under debate, as I see it, is the utility of speeding > up the "benchmarks" of folks who compare the speed of Python and > another language doing a very simple loop over the lines in a file. If that were true, I couldn't care less. > Since this advantage disappears once real work is being done on > the file, ... I agree that's true, but submit it's rarely relevant. *Most* file-crunching apps are dominated by I/O time, which is why this is so visible to so many; e.g., chewing over massive log files looking for patterns appears to be the growth industry of the 21st century <wink>. Even in Lutz's report (see reference from earlier mail), where the task to be solved was far from trivial, input time exceeded processing time across all languages (with some oddball exceptions, when the coder neglected to use a hash table to store info). That's thoroughly typical of real file-crunching applications, in my experience: Perl has a killer speed advantage in the single most time-consuming portion of the app, and due to one implementation trick. Take that advantage away, and Python holds its own in this domain. Coincidentally, I got pvt email from a newbie today, reading in part; > If Perl wasn't so gosh darn good and fast at text scrubbing, it > wouldn't really be a consideration, it's syntax is so clunky and > hard to learn by comparison to both Python and Ruby. This is just depressing, because I can predict every step of this dance. > ... > Happy new year, all. And to you! Just make sure it's a fast new year <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4