[Boston.pm] Meeting next Tuesday, Feb 8th ?

2011-02-04 Thread Bill Ricker
I am unable to attend next Tuesday. Uri has volunteered to be acting acting Facilitator. He does need someone to volunteer to present. -- Bill @n1vux bill.n1...@gmail.com ___ Boston-pm mailing list Boston-pm@mail.pm.org

[Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Asa Martin
I was going over some code at work and I suggested the following code changes while processing a four column file with columns that contain domain, subdomain, rule, and label. What those fields actually mean are irrelevant to this discussion, although they're all short character strings. Suffice

Re: [Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Justin Hunter
what's wrong with my ($domain, $subdomain, $rule, $label); while (FH) { chomp; ($domain, $subdomain, $rule, $label) = split /\t/; } Justin On Fri, Feb 4, 2011 at 5:04 PM, Asa Martin asa.mar...@gmail.com wrote: I was going over some code at work and I suggested the following code

Re: [Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Conor Walsh
On 2/4/2011 2:04 PM, Asa Martin wrote: I was told that predeclaring the variables outside the loop saved on memory allocation, and that using @rules instead of four named variables was also more efficient. I had never considered that this could be the case, and said I didn't think this was true,

Re: [Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Michael Small
Asa Martin asa.mar...@gmail.com writes: ... my ($line, @rules); while ($line = FH) { chomp $line; @rules = split(\t, $line); do stuff with $rules[0], $rules[1], $rules[2] and $rules[3] ... Here were my proposed changes: while (my $line = FH) { chomp $line; my

[Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Bob Rogers
From: Asa Martin asa.mar...@gmail.com Date: Fri, 4 Feb 2011 17:04:35 -0500 . . . I was told that predeclaring the variables outside the loop saved on memory allocation, IIUC, all of those scratchpad variables are created on sub entry. The performance difference of predeclaring

Re: [Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Greg London
If the question is which is faster, then one could pontificate endlessly about potential permutations of perl compiler patterns that may or may not come to pass. Or. One could download one of the myriad of benchmakrking modules and let objective data win over various perl myths. Greg

[Boston.pm] Q: giant-but-simple regex efficiency

2011-02-04 Thread Kripa Sundar
Hi folks, Problem: I have a 900 Meg text file, containing random text. I also have a list of 6000 names (alphanumeric strings) that occur in the random text. I need to tag a prefix on to each occurrence of each of these 6000 names. My premise: I believe a regex would give the simplest and most

Re: [Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Conor Walsh
On 2/4/2011 3:37 PM, Uri Guttman wrote: now, depending on how large the file is, slurping it may be faster than reading it line by line (larger files will win more). the reason is perl's stream i/o is slower than a single slurp. Slurping is fun, but only works if you can fit the file in memory.

Re: [Boston.pm] Q: giant-but-simple regex efficiency

2011-02-04 Thread Uri Guttman
KS == Kripa Sundar kripa.sun...@synopsys.com writes: KS I have a 900 Meg text file, containing random text. I also have a list KS of 6000 names (alphanumeric strings) that occur in the random text. KS I need to tag a prefix on to each occurrence of each of these 6000 KS names. KS My

Re: [Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Uri Guttman
CW == Conor Walsh c...@adverb.ly writes: CW On 2/4/2011 3:37 PM, Uri Guttman wrote: now, depending on how large the file is, slurping it may be faster than reading it line by line (larger files will win more). the reason is perl's stream i/o is slower than a single slurp. CW

Re: [Boston.pm] Q: giant-but-simple regex efficiency

2011-02-04 Thread Greg London
I wrote Parse::Gnaw to parse a file a little bit at a time using a real grammer. I was dealing with multi gigabyte text files that represented a gate level version of an ASIC. As long as the text you are parsing can be defined in chunks and you can flush at the end of a chunk then

Re: [Boston.pm] [Boston.pm-announce] Meeting next Tuesday, Feb 8th ?

2011-02-04 Thread Bill Ricker
Redirecting discussion to discussion list ... Sorry I'll miss Tad, me traded email and voicemail back in StoneHenge days. On Fri, Feb 4, 2011 at 4:26 PM, Federico Lucifredi flucifr...@acm.org wrote: I am interested in seeing the File::Slurp update! Will be there. As would I if I could attend.

Re: [Boston.pm] [Boston.pm-announce] Meeting next Tuesday, Feb 8th ?

2011-02-04 Thread Conor Walsh
I suppose I have a new valid answer to my favorite do you really know Perl or do you just know the syntax interview question. Curse you, Federico and Robbie. -C. On Fri, Feb 4, 2011 at 5:18 PM, Bill Ricker bill.n1...@gmail.com wrote: Redirecting discussion to discussion list ... Sorry I'll

Re: [Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Bill Ricker
On Fri, Feb 4, 2011 at 6:59 PM, Uri Guttman u...@stemsystems.com wrote: agreed. i never advocate slurping for GB files as thrashing will kill Aside from Windows, 64 bit Perl on a modern machine should be to slurp a multi gigabyte file ! -- Bill @n1vux bill.n1...@gmail.com

Re: [Boston.pm] [Boston.pm-announce] Meeting next Tuesday, Feb 8th ?

2011-02-04 Thread Uri Guttman
CW == Conor Walsh c...@adverb.ly writes: CW I suppose I have a new valid answer to my favorite do you really know CW Perl or do you just know the syntax interview question. Curse you, CW Federico and Robbie. my favorite part is that he calls delete but doesn't realize it has a useful

Re: [Boston.pm] Question on optimization/memory allocation

2011-02-04 Thread Uri Guttman
BR == Bill Ricker bill.n1...@gmail.com writes: BR On Fri, Feb 4, 2011 at 6:59 PM, Uri Guttman u...@stemsystems.com wrote: agreed. i never advocate slurping for GB files as thrashing will kill BR Aside from Windows, 64 bit Perl on a modern machine should be to slurp BR a multi gigabyte