To all the Boston.pm readers who responded...
I would like to thank you all.
From the various suggestions offered I was able to try virtually ALL of
them to isolate where the bottleneck was occuring. And, of course,
learn along the way which methods perform better on our installation(s).
On Wednesday, June 18, 2003, at 01:02 PM, Bob Mariotti wrote:
I have something that works but the timing is just tooo slow. I
have a subroutine that communications with remote hosts. It simply
passes a one line string as a request and receives back from 1 to 100+
lines of text in return.
I don't know if either of these really address the performance issue,
but ...
$REC=;
$REC=CXIBIO;
the first assignment serves no purpose since you are immediately
overwriting it.
# Contruct Host Response String
$RECIN=$RECIN.$REC;
Would the Perl compiler generate better code for
$RECIN .=
Have you tested the subroutine without any data
assignments, just:
open(CXIBIO,+$ARGV[0]) or die Could NOT open $ARGV[0]\n;
print CXIBIO $ARGV[1]\015;
EP: while (1)
{
$REC=CXIBIO;
if ( $REC =~ m/[EMAIL PROTECTED]/) { next EP; }
if ( $REC =~ m/^0999/) { last EP; }
}
At 1:02 PM -0400 6/18/03, Bob Mariotti wrote:
I have something that works but the timing is just tooo slow. I
have a subroutine that communications with remote hosts. It simply
passes a one line string as a request and receives back from 1 to
100+ lines of text in return.
As this is done
On Wed, Jun 18, 2003 at 01:02:16PM -0400, Bob Mariotti wrote:
However, when timing the snippet below, it takes over 12 seconds to
complete. That's 8 seconds (and that's an eternity) to respond.
Have you tried using a non-Perl client? Something like netcat