Re: Serious performance bug in Perl
As the proud owner of that particular patch, I guess I should say something... :) Daniel == Daniel Martin at cush [EMAIL PROTECTED] writes: Daniel Ok, I've looked at it. Daniel I really don't know quite what to do with this. On the Daniel one hand, automatically reading the shadow password Daniel entries is desireable since it keeps old scripts working Daniel without knowing whether shadow passwords are being used or Daniel not. On the other hand, doing a getspnam for every getpw* Daniel call causes serious performance issues. When I wrote the patch, I didn't have a 3000 entry /etc/passwd so was unaware of any major performance issue with getspnam. Daniel The solution, as I said before, seems to be invoking some Daniel kind of magic on the scalar that's second in the list Daniel returned by getpw*. (what traditionally is the encrypted Daniel password field) This, IMHO, is overkill. A less intrusive solution may be to do an setspent call in the setpwent code within p_sys.c. Unfortunately, my getspent man page seems to have gone missing so I can't check on the feasiblity of this solution right now. Daniel Here's the problem: Perl has various kinds of builtin Daniel magics, but all of them do highly specialized things, such Daniel that adding a new kind of builtin magic necessitates Daniel changes in several different places, and any new shadow Daniel password entry magic type might be incompatible with Daniel future versions of perl. Now there are two types of magic Daniel reserved for use by extensions, but I'm loathe to use them Daniel since it's hard to avoid name conflicts with those magics; Daniel also, changing getpw* mucks with perl's internal code and Daniel the docs seem to suggest that internal perl procedures Daniel shouldn't use those types of magics. (Admittedly, a bit Daniel of U-type magic might serve as a temporary fix, and may Daniel be the best (read: most easily implemented) solution at Daniel the moment) If you wanted to go that route it would make more sense to do a hidden tie on the pw scalar and use that to control the lookup. The you'd just have to find an appropriate namespace for such a beast. Daniel Also, is the Cc: list on this mail too broad? Should Daniel someone else be getting these messages too? Should this Daniel be taken off debian-devel? It should, in fact, be on the p5p list. -- Stephen --- all coders are created equal; that they are endowed with certain unalienable rights, of these are beer, net connectivity, and the pursuit of bugfixes... - Gregory R Block -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
Darren/Torin/Who Ever... [EMAIL PROTECTED] writes: -BEGIN PGP SIGNED MESSAGE- Daniel Martin, in an immanent manifestation of deity, wrote: My... it's been a while since I was investigating perl internals (writing C code that was callable from perl) - at least two years, which somehow seems much longer. Well, I'll have my machine download the perl source tonight and see what I can see... Thanks for taking a look at this. I won't have time to do so until Tuesday; it being Solstice Weekend and all. Darren Ok, I've looked at it. I really don't know quite what to do with this. On the one hand, automatically reading the shadow password entries is desireable since it keeps old scripts working without knowing whether shadow passwords are being used or not. On the other hand, doing a getspnam for every getpw* call causes serious performance issues. The solution, as I said before, seems to be invoking some kind of magic on the scalar that's second in the list returned by getpw*. (what traditionally is the encrypted password field) Here's the problem: Perl has various kinds of builtin magics, but all of them do highly specialized things, such that adding a new kind of builtin magic necessitates changes in several different places, and any new shadow password entry magic type might be incompatible with future versions of perl. Now there are two types of magic reserved for use by extensions, but I'm loathe to use them since it's hard to avoid name conflicts with those magics; also, changing getpw* mucks with perl's internal code and the docs seem to suggest that internal perl procedures shouldn't use those types of magics. (Admittedly, a bit of U-type magic might serve as a temporary fix, and may be the best (read: most easily implemented) solution at the moment) Now, add to that the fact that it wouldn't be all that hard to write a perl module (called, say, ShadowPasswd) that would provide replacement getpw* functions (yes, one can replace perl builtin functions with ones from modules), as well as proper getsp* functions, and could handle the magic nicely so that getspnam isn't called unnecessarily through a tied scalar. (I am aware of the Shadow module written for 5.003 that provides some small interface to getsp* - this would do more) This really seems the cleanest solution, and may indeed be easier to implement than the U-magic method. (Note that with this, it would even be possible to create a shadow-aware setpwent; I still need to think out the details and implications of that, though) The only problem now is that scripts would have to say use ShadowPasswd; or they wouldn't have shadow password support - this could potentially break many scripts. So, some might say that the solution is to have getpw* autoload the ShadowPasswd module; if I could figure out how to do this, I'd say that this is the solution we should shoot for. Unfortunately, I got lost somewhere in the perl source code and couldn't find my way to how that might be done. Also, is the Cc: list on this mail too broad? Should someone else be getting these messages too? Should this be taken off debian-devel? DANIEL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
Chris Fearnley [EMAIL PROTECTED] writes:
On Thu, Jun 18, 1998 at 12:38:45PM -0500, Richard Kaszeta wrote:
Christopher J. Fearnley writes (Re: Serious performance bug in Perl):
to call it (instead of the default perl - 5.004.04-6). Performance
improved several hundred-fold. So I believe the problem is either in
perl or libc6.
Any suggestions on how to resolve this? As I said before the slowdown
seems to occur in the get_current_uids subroutine (and possible
get_current_gids). Which has a loop on getpwent (and getgrent).
Can anyone else duplicate this behavior?
I can duplicate this behavior. Performance gets exponentially better
if I move my NIS password records into the local password file. So in
my case I am tempted to blame libc6's NIS performance (which in other
circumstances I have found to be rather slow anyways)
Are you running NIS?
--
Richard W Kaszeta Graduate Student/Sysadmin
[EMAIL PROTECTED] University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta
It's a perl thing. I can almost guarantee it. The problem is perl's
shadow password support and it's getpw* functions. Whenever these
functions are called (and assigned to a variable; if you just call
them and discard the value immediately this doesn't happen), perl
attempts to look up the shadow password entry associated with the
given struct passwd *, and this takes a while - especially since the
/etc/shadow file is closed immediately after each fetch. (Which could
be because perl is doing something like a getspnam call each time - of
course, since it's doing these getspnam calls in order, one might think
that perhaps libc6 should be smart enough to not close and re-open
/etc/shadow each time, but maybe perl surrounds the getspnam calls
with setspent() and endspent() calls or somesuch for security
reasons).
This clearly seems to be a case that calls for a bit of magic (as in
magic variables that invoke arbitrary code each time they're
referenced) - the second element of the list returned by getpw* should
be a magic scalar, which is looked up only when asked for. Could be
an idea that gets forwarded upstream.
In any case, at the moment you should be able to speed adduser up
considerably by modifying the get_current_uids routine as follows:
sub get_current_uids {
my(@uids, $uid);
my($olduid);
$olduid = $;
$ = $;
$ = ((getpwnam nobody)[2]);
setpwent;
push @uids, $uid while defined($uid = (getpwent)[2]);
endpwent;
$ = $;
$ = $olduid;
@uids;
}
(This should work even if adduser is made an suid script executable by
only a certain group)
This still causes (you can see with an strace) many attempts to open
/etc/shadow, but they're all denied so the whole process is much faster.
For what it's worth, I made libc5 and libc6 C programs that just
called getpwent or getspent repeatedly - both blazed through my 1000
user passwd and shadow files in well under 0.05 sec each, though the
libc5 one was about twice as fast on getpwent and the libc6 one was
about twice fast on getspent. Go figure.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
Daniel == Daniel Martin at cush [EMAIL PROTECTED] writes: Daniel It's a perl thing. I can almost guarantee it. The Daniel problem is perl's shadow password support and it's getpw* Daniel functions. Whenever these functions are called (and Daniel assigned to a variable; if you just call them and discard Daniel the value immediately this doesn't happen), perl attempts Daniel to look up the shadow password entry associated with the Daniel given struct passwd *, and this takes a while - especially Daniel since the /etc/shadow file is closed immediately after Daniel each fetch. This is probably because the patch that allows Debian's Perl to use getspnam() and friends is pretty new and untested. Is there any way you can look at http://www.rosat.mpe-garching.mpg.de/mailing-lists/perl-porters/1998-03/msg01574.html and see if the patch there can be made better? Let's try to fix this problem. Ben -- Brought to you by the letters S and X and the number 14. XTC versus Adam Ant -- which one will survive? -- They Might Be Giants Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
Ben Gertzfield [EMAIL PROTECTED] writes: Daniel == Daniel Martin at cush [EMAIL PROTECTED] writes: Daniel It's a perl thing. I can almost guarantee it. The Daniel problem is perl's shadow password support and it's getpw* Daniel functions. Whenever these functions are called (and Daniel assigned to a variable; if you just call them and discard Daniel the value immediately this doesn't happen), perl attempts Daniel to look up the shadow password entry associated with the Daniel given struct passwd *, and this takes a while - especially Daniel since the /etc/shadow file is closed immediately after Daniel each fetch. This is probably because the patch that allows Debian's Perl to use getspnam() and friends is pretty new and untested. Is there any way you can look at http://www.rosat.mpe-garching.mpg.de/mailing-lists/perl-porters/1998-03/msg01574.html and see if the patch there can be made better? Let's try to fix this problem. My... it's been a while since I was investigating perl internals (writing C code that was callable from perl) - at least two years, which somehow seems much longer. Well, I'll have my machine download the perl source tonight and see what I can see... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
-BEGIN PGP SIGNED MESSAGE- Daniel Martin, in an immanent manifestation of deity, wrote: My... it's been a while since I was investigating perl internals (writing C code that was callable from perl) - at least two years, which somehow seems much longer. Well, I'll have my machine download the perl source tonight and see what I can see... Thanks for taking a look at this. I won't have time to do so until Tuesday; it being Solstice Weekend and all. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI programmer and tutor. @ @Make a little hot-tub in your soul. @ -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNYrkd44wrq++1Ls5AQE60AQAgp7zWlwWvs0usGU/V+C2zGVh6I7st/ir qPGabYlDtF6nm/nIL8K5BzH+4v7oZw2NhKfdFY3793HoIbgJE2uUqYqcNnc3BDRf +k2A3H1o06UQk071b46ne5L7JN776ta3eHWL0VnxkoWmyJlm1a+4JHZ4P+pRvGfH bq1SrTAUguw= =YeSA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
On Mon, Jun 15, 1998 at 04:43:13AM -0700, Darren/Torin/Who Ever... wrote: Chris Fearnley, in an immanent manifestation of deity, wrote: But yesterday I upgraded a bo system to hamm which has a 3000 line /etc/passwd. Now adduser takes OVER ONE MINUTE to find a UID and GID for the new user. And my staff is complaining about the wasted time. Something is wrong with your installation or possibly libc. I compiled perl-5.003_07 and perl-5.004_04 on a Solaris box with 5000 users. The 5.004_04 was somewhat faster. I installed perl-5.003_07 (from bo - hence libc5) and modified adduser to call it (instead of the default perl - 5.004.04-6). Performance improved several hundred-fold. So I believe the problem is either in perl or libc6. Any suggestions on how to resolve this? As I said before the slowdown seems to occur in the get_current_uids subroutine (and possible get_current_gids). Which has a loop on getpwent (and getgrent). Can anyone else duplicate this behavior? -- Christopher J. Fearnley | Linux/Internet Consulting [EMAIL PROTECTED] | Design Science Revolutionary http://www.i21.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | Dare to be Naive -- Bucky Fuller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
Christopher J. Fearnley writes (Re: Serious performance bug in Perl): to call it (instead of the default perl - 5.004.04-6). Performance improved several hundred-fold. So I believe the problem is either in perl or libc6. Any suggestions on how to resolve this? As I said before the slowdown seems to occur in the get_current_uids subroutine (and possible get_current_gids). Which has a loop on getpwent (and getgrent). Can anyone else duplicate this behavior? I can duplicate this behavior. Performance gets exponentially better if I move my NIS password records into the local password file. So in my case I am tempted to blame libc6's NIS performance (which in other circumstances I have found to be rather slow anyways) Are you running NIS? -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
I have missed a bit of the conversation here, so it isn't clear to me which lib6 is being used. I am currently preparing the 2.0.7 release version. To the best of my knowledge the 2.0.7pre3 (in slink...sorry) had some major NIS work done on it, but there isn't anything between then and now. If 2.0.7pre3 isn't an improvement over pre1, then I need to know about it, and what is causing it so I can complain upstream about it ;-) Thanks, On Thu, 18 Jun 1998, Richard Kaszeta wrote: Christopher J. Fearnley writes (Re: Serious performance bug in Perl): to call it (instead of the default perl - 5.004.04-6). Performance improved several hundred-fold. So I believe the problem is either in perl or libc6. Any suggestions on how to resolve this? As I said before the slowdown seems to occur in the get_current_uids subroutine (and possible get_current_gids). Which has a loop on getpwent (and getgrent). Can anyone else duplicate this behavior? I can duplicate this behavior. Performance gets exponentially better if I move my NIS password records into the local password file. So in my case I am tempted to blame libc6's NIS performance (which in other circumstances I have found to be rather slow anyways) Are you running NIS? -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
No, I am not running NIS. Just simple text /etc/passwd and /etc/shadow. On Thu, Jun 18, 1998 at 12:38:45PM -0500, Richard Kaszeta wrote: Christopher J. Fearnley writes (Re: Serious performance bug in Perl): to call it (instead of the default perl - 5.004.04-6). Performance improved several hundred-fold. So I believe the problem is either in perl or libc6. Any suggestions on how to resolve this? As I said before the slowdown seems to occur in the get_current_uids subroutine (and possible get_current_gids). Which has a loop on getpwent (and getgrent). Can anyone else duplicate this behavior? I can duplicate this behavior. Performance gets exponentially better if I move my NIS password records into the local password file. So in my case I am tempted to blame libc6's NIS performance (which in other circumstances I have found to be rather slow anyways) Are you running NIS? -- Richard W Kaszeta Graduate Student/Sysadmin [EMAIL PROTECTED] University of MN, ME Dept http://www.menet.umn.edu/~kaszeta -- Christopher J. Fearnley | Internet21 Network Engineering [EMAIL PROTECTED] | Design Science Revolutionary http://www.i21.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | Dare to be Naïve -- Bucky Fuller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
'Darren/Torin/Who Ever... wrote:' Chris Fearnley, in an immanent manifestation of deity, wrote: But yesterday I upgraded a bo system to hamm which has a 3000 line /etc/passwd. Now adduser takes OVER ONE MINUTE to find a UID and GID for the new user. And my staff is complaining about the wasted time. I fear that this perl bug is serious. Something is wrong with your installation or possibly libc. I compiled perl-5.003_07 and perl-5.004_04 on a Solaris box with 5000 users. The 5.004_04 was somewhat faster. Maybe it's a problem with perl on libc6 systems with shadow passwords??? It was a straightforward upgrade from bo. I can't imagine how a misconfiguration could cause this. I have the latest of everything relevant installed: [EMAIL PROTECTED]:~$ dpkg -l libc6 perl passwd adduser Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii libc6 2.0.7pre1-4The GNU C library version 2 (run-time files) ii perl5.004.04-6 Larry Wall's Practical Extracting and Report ii passwd 980403-0.2 Change and administer password and group dat ii adduser 3.8Add users and groups to the system. [EMAIL PROTECTED]:~$ ls -l /etc/passwd /etc/shadow /etc/group /etc/gshadow -rw-r--r-- 1 root root48419 Jun 15 21:41 /etc/group -rw-r- 1 root shadow 35754 Jun 15 21:41 /etc/gshadow -rw-r--r-- 1 root root 191178 Jun 15 21:41 /etc/passwd -rw-r- 1 root shadow 124656 Jun 15 21:41 /etc/shadow Could it be a problem with shadow passwords? -- Christopher J. Fearnley | Linux/Internet Consulting [EMAIL PROTECTED] | Design Science Revolutionary http://www.netaxs.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | Dare to be Naïve -- Bucky Fuller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
-BEGIN PGP SIGNED MESSAGE- Chris Fearnley, in an immanent manifestation of deity, wrote: But yesterday I upgraded a bo system to hamm which has a 3000 line /etc/passwd. Now adduser takes OVER ONE MINUTE to find a UID and GID for the new user. And my staff is complaining about the wasted time. I fear that this perl bug is serious. Something is wrong with your installation or possibly libc. I compiled perl-5.003_07 and perl-5.004_04 on a Solaris box with 5000 users. The 5.004_04 was somewhat faster. Darren - -- [EMAIL PROTECTED] http://www.daft.com/~torin [EMAIL PROTECTED] [EMAIL PROTECTED] Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996 @ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI programmer and tutor. @ @Make a little hot-tub in your soul. @ -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNYUI0I4wrq++1Ls5AQGfbwQAiE+bng5N1BUcym9pRgOSE4Zj2RK4VZC+ sECRIRfju7wAuVkMkMviKI8OkDsxh+D8nSsv1IKq4PTpKJ3bScIxYfqKwDUkZHjg bD4SzGYFLZVUsNVuOG8qjMkd7KyFcO4YDZICJ982Vp9fE6BrhgeJkVb7c19LuMn7 xokFKEf3jDE= =Uvmx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Serious performance bug in Perl
Previously Chris Fearnley wrote: But yesterday I upgraded a bo system to hamm which has a 3000 line /etc/passwd. Now adduser takes OVER ONE MINUTE to find a UID and GID for the new user. And my staff is complaining about the wasted time. Are you sure it's a problem with perl? I've had the same problem with tar becoming dog-slow because I had `compat' in /etc/nsswitch.conf. Changing that to `nis files' fixed the speed-problem. You could probably use strace to check what is really causing the delay. Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpXMThR3Sf7m.pgp Description: PGP signature
Re: Serious performance bug in Perl
'Wichert Akkerman wrote:'
Previously Chris Fearnley wrote:
But yesterday I upgraded a bo system to hamm which has a 3000 line
/etc/passwd. Now adduser takes OVER ONE MINUTE to find a UID and GID
for the new user. And my staff is complaining about the wasted time.
Are you sure it's a problem with perl? I've had the same problem with
tar becoming dog-slow because I had `compat' in /etc/nsswitch.conf.
Changing that to `nis files' fixed the speed-problem.
Goodness, the libc6 docs on the NSS mechanism are horrible. But in
the interests of experimentation, I tried changing this from compat
to files. Still dog-slow.
You could probably use strace to check what is really causing the delay.
Wichert.
I did try strace it looked like it was doing illions of open's and
then mmap's on /etc/shadow at the point where it was slow. Here is
the recurring part of the strace:
open(/etc/shadow, O_RDONLY) = 5
fcntl(5, F_GETFD) = 0
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
fstat(5, {st_mode=0, st_size=0, ...}) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40126000
lseek(5, 0, SEEK_CUR) = 0
read(5, root
...
After 12 reads on /etc/shadow, it repeats. I added print statements
to adduser and it looks like it was the get_current_uid subroutine
where the performance problem occurs. It has a loop on getpwent.
Maybe it's the C library that is buggy?
--
Christopher J. Fearnley | Linux/Internet Consulting
[EMAIL PROTECTED] | Design Science Revolutionary
http://www.netaxs.com/~cjf | Explorer in Universe
ftp://ftp.netaxs.com/people/cjf | Dare to be Naïve -- Bucky Fuller
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Serious performance bug in Perl
Hi, Originally I thought that it was OK that bug #19085 which I submitted about poor performance in perl was downgraded from important to normal severity because it only affected one application that I wrote. But yesterday I upgraded a bo system to hamm which has a 3000 line /etc/passwd. Now adduser takes OVER ONE MINUTE to find a UID and GID for the new user. And my staff is complaining about the wasted time. I fear that this perl bug is serious. But I haven't heard anyone else complain (I have been remiss in reading the lists lately). Am I the only seeing severe performance degradation with Perl 5.004_04 ? Can anyone else with large password files duplicate the problem? -- Christopher J. Fearnley | Linux/Internet Consulting [EMAIL PROTECTED] | Design Science Revolutionary http://www.netaxs.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | Dare to be Naïve -- Bucky Fuller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
