NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
and option #3 (Score:2)
Re:and option #3 (Score:1)
Only the new ones.
Re:and option #3 (Score:2)
Also for large systems there comes the tipping point where developer time actually becomes cheaper than the costs of machines, maintenance and rack space. It's these sort of entities who were asking the question.
Re:and option #3 (Score:2)
Reply to This
Parent
Re:and option #3 (Score:2)
It was firms with over 50,000 lines of perl code that were thinking about it, one of which I know is running code across several hundred servers. I doubt that re-writing the whole thing in C (or anything) is easy, as I'm guessing that the cost of validating that the behaviour is the same is prohibitive, but re-writing parts might well be, if those parts can be identified. But I think that both were thinking that it still might be easier to concentrate resources on the core, as that could speed up all code,
Re:and option #3 (Score:2)
Well, with something like that you have to consider so many other possible bottlenecks, especially since much of the clustering software, if that's what they're using, do exact a speed toll. I'd call them outright awful, but a few of them do actually manage to work on occasion.
And, given the pain and suffering involved with changing most anything in the perl core, *ahem*, I'd guess that rewriting large parts or the whole thing would be faster and far less hassle with a greater performance gain. Anyone w