[code-review] list scope
"Hodges, Paul" <Paul.Hodges-zv7RHi0Am8a1Z/[email protected]> Thu, 11 Sep 2003 11:55:31 -0500
| Newsgroups | gmane.comp.lang.perl.code-review-ladder |
|---|---|
| Message-ID | <9C375DDD9B669243A2D78FCD607E894003E4FC4A@bremo-jg> |
So what's the official scope of the list? Consider this a pre-spam question to prevent the real spam. :) I have a Perl object module for a file structure we use at work, written in Inline::C for performance, but it's pretty big, and technically contains proprietary file structure information. Is it appropriate for this list to supply a detailed-but-altered dummy version to get some algorithm fine-tuning feedback? In general, I love all the advantages of objects, and I adore Perl, and I think Perl's object model is pretty sweet, but haven't been able to produce a parsing object in pure Perl that doesn't take four hours or more to run through a file, while the C version can do it in a half hour. For any more detailed (and thus realistic) benchmark, the ratio comes out at more like 8 or even 10 to one. I'd rather do it all in Perl to reduce complexity, but may not be able to for performance reasons. Even in C I still need to streamline it, because we are rather more often than not asked to do surveys across files representing data from multiple states and/or months, which means that even at the realistic time expenditure of an hour per file in hard C code, it sometimes takes days to run AFTER all the preliminary testing....and then we find something iffy that needs tweaking, and then have to re-run it. Such projects are always sudden, and ad-hoc, and expect data back yesterday. Until we get our database up (expect months or years) we're stuck with this method, and our group exists for quick turnaround of data that the IT department's paperwork division makes impossible. So is it cool to post entire modules and the scripts that use them, possibly in multiple incarnations? ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers."