This is very slow on Mac OS X 10.3.

real    14m36.335s
user    13m33.220s
sys     0m4.200s
[download]

From the Mac OS X 10.3 crypt() man page:

The first argument to crypt() is a null-terminated string, typically a user's typed password. The second is in one of two forms: if it begins with an underscore ("_") then an extended format is used in interpreting both the key and the setting, as outlined below.

Extended crypt: The key is divided into groups of 8 characters (the last group is null- padded) and the low-order 7 bits of each each character (56 bits per group) are used to form the DES key as follows: the first group of 56 bits becomes the initial DES key. For each additional group, the XOR of the encryption of the current DES key with itself and the group bits becomes the next DES key.

The setting is a 9-character array consisting of an underscore followed by 4 bytes of iteration count and 4 bytes of salt. These are encoded as printable characters, 6 bits per character, least significant character first. The values 0 to 63 are encoded as "./0-9A-Za-z". This allows 24 bits for both count and salt.

Traditional crypt: The first 8 bytes of the key are null-padded, and the low-order 7 bits of each character is used to form the 56-bit DES key.

The setting is a 2-character array of the ASCII-encoded salt. Thus only 12 bits of salt are used. count is set to 25.

I believe the iteration count works out to 6639540 in the first crypt() call.

Update: My point is that since the first crypted string starts with "_" it's triggering this extended crypt() algorithm that takes (in this case) about 260,000 times as long as the traditional crypt() algorithm.

A workaround is to insert any additional character (other than "_", of course) at the beginning of the first line after the __END__.

You do realize that the underscore in /_{2}(.+$)/ matches the underscores before END and not the underscores after it, right?