Skip Menu |

This queue is for tickets about the Net-Telnet CPAN distribution.

Report information
The Basics
Id: 4151
Status: rejected
Priority: 0/
Queue: Net-Telnet

People
Owner: Nobody in particular
Requestors: adam [...] fordys.net
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: Slow performance when pulling back large data
Net::Telnet 3.0.3 This is perl, v5.6.1 built for sun4-solaris SunOS XXXXX.fordys.net 5.8 Generic_108528-20 sun4u sparc SUNW,Ultra-4 If you try pulling back large amounts of data over a telnet session, it can take a long time, and hog a lot of CPU time to pull the data back. I believe this is due to the entire buffer downloaded so far being scanned for the 'waitfor' prompts every n bytes downloaded. If your pulling down 1Mb of text data, this buffer can get very large, so the code is constantly cycling over this entire 1Mb of data looking for the waitfor prompt-- essentially doing the same work multiple times. I have made some Temporary "belt and braces" modifications to Telnet.pm, which only scan the list n bytes of the buffer instead, and I've improved the performance by at least over 5 times. (The more data you pull, the more CPU it saves). Can someone have a look at this? It'd be great if this could be fixed in a future distribution, rather than me manually modifying Telnet.pm everywhere :o) Regards, Adam.
Guest via RT wrote: Show quoted text
> If you try pulling back large amounts of data over a telnet > session, it can take a long time, and hog a lot of CPU time to > pull the data back. I believe this is due to the entire buffer > downloaded so far being scanned for the 'waitfor' prompts every > n bytes downloaded. > > If your pulling down 1Mb of text data, this buffer can get very > large, so the code is constantly cycling over this entire 1Mb > of data looking for the waitfor prompt-- essentially doing the > same work multiple times.
Yes I believe that's correct. However since so few users are pulling down anything close to 1MB of output from a command, I consider this a low priority fix. The work-around is to read a block at a time and scan for the prompt. There's an example in the Net::Telnet "man" page on how to do this. See the example on how to down load a file of any type.
I'm sorry but I think the performance problem described is best handled by the users modifying their code to use get() instead of waitfor(). Thanks for pointing out this problem.