Comments on: Optimizing Searches In Perl https://pthree.org/2006/12/18/optimizing-searches-in-perl/ Linux. GNU. Freedom. Thu, 15 Feb 2018 18:04:15 +0000 hourly 1 https://wordpress.org/?v=5.0-alpha-42199 By: Harley Pig https://pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22252 Tue, 19 Dec 2006 17:45:32 +0000 http://www.pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22252 That first if block, where you're reading in the first file would be much faster with this:

%phone = map { ( unpack $layout1, $_ ) , $_ } <$IN1>

]]>
By: Harley Pig https://pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22251 Tue, 19 Dec 2006 17:37:45 +0000 http://www.pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22251 Jayce--arghh ... yeah ... I'm still trying to internalize that one.

> <

]]>
By: Jayce^ https://pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22249 Tue, 19 Dec 2006 17:18:30 +0000 http://www.pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22249 Matthew - In fixed width data especially, unpack is much faster, it has no need to save state, load a complex engine, or other background tasks it would need. He still *could* have used them, but this is much more efficient.

Harleypig - as for : print “Match: ” . $counter++ . “\r”

just to be pedantic to you 🙂 dont' use the concat operator (.) in a print. If you think about it the print operator is set to handle arrays, so why not just give it one. Benchmark the difference to verify, but using concat will force it to concat a new string first, then print, instead of print array.

]]>
By: Aaron Toponce » Blog Archive » Using GeSHi https://pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22236 Tue, 19 Dec 2006 15:49:38 +0000 http://www.pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22236 [...] One of the strong features in GeSHi, is the ability to recognize keywords and functions built into the language, and provide a link to the official documentation about that keyword. You may have noticed this with my last post about optimizing searches in Perl. Clicking on one of the functions will take to the Perl documentation site about that function. Try ‘print’ or ‘open’ to see what I am talking about. [...]

]]>
By: Aaron https://pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22229 Tue, 19 Dec 2006 15:06:10 +0000 http://www.pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22229 Matthew-

In this case, no. The files that I am searching have no rhyme and reason to the layout. Well, they do, but it differs from file to file, and I don't know before hand what the layout will be. I only know where certain variables are in the layout. So, with that, I can just use substr() or unpack(), as seen here, to get right to where I need to be in the file.

]]>
By: Matthew Kimber https://pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22227 Tue, 19 Dec 2006 15:01:56 +0000 http://www.pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22227 Couldn't you have just used regular expressions?

]]>
By: Aaron https://pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22149 Mon, 18 Dec 2006 23:04:45 +0000 http://www.pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22149 harleypig- thx for your response. A couple of things:

1) WordPress likes to lowercase anything that sits between < and >. As in the case with this code, it got lower case, but I do use uppercase filehandles. Also, you’ll notice “# </in1>”. This is because WordPress will automatically close my tags if I don’t, so I just put it in the code.
2) I store the line of the key in the hash, because I actually am using it later. I probably shouldn’t have put it in my example code.
3) I think some of your example is preference to the programmer, but at any case, goes to show that there is more than one way to skin a cat! But I agree that it could get a bit more efficient.

]]>
By: Harley Pig https://pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22144 Mon, 18 Dec 2006 22:20:59 +0000 http://www.pthree.org/2006/12/18/optimizing-searches-in-perl/#comment-22144 #!/usr/bin/perl -w

use strict;

# I realize a lot of these are not
# specifically related to your problem
# but I'm pedantic.

# First, filehandles in perl are
# idiomatically uppercase, just to
# help distinguish them.
#
# Second, use variable filehandles. It
# makes error handling easier.
#
# Third, predeclare as much as possible.
# It'll save a little bit of time. Right
# now you're declaring a variable every
# time through both loops, but it's not
# changing.

# I don't use (un)pack that often so I
# can't comment on that.

my %phone;

my $layout1 = '@1384 A10';
my $layout2 = '@0 A10';

if ( open my $IN1, "P1514.FIN" ) {

while( ) {

chomp;

# You don't need to assign a variable
# for temporary use, it just slows you
# down and takes up memory.

# Why are you saving the line if you're
# not using it later?
$phone{ unpack $layout1, $_ } = '';

}

# $IN1 loses scope here. Perl will
# automatically close the file.

} else {

# It's confusing when you get bogus data,
# or no data.

die "Unable to open P1514.FIN: $!\n";

}

if ( open my $IN2, "p1514.afo" ) {

my $counter = 0;

while( ) {

# I'm not sure what you're trying to
# accomplish here, but taking what you
# have, you can increase the efficiency
# quite a bit by using a little more
# idiomatic perl.

print "Match: " . $counter++ . "\r"
if exists $phone{ unpack $layout2, $_ };

}
} else {

die "Unable to open p1514.afo: $!\n";

}

print "\n";

# Not having a copy of the data I can't test this
# but it passes perl -c

]]>