1) If I understand that sub correctly you are creating your password by shuffling the whole list of available chars 5 times to generate a 5 char password (why not just pick a random char with rand(@char) instead?), then you put that string into a rapidly increasing hash that will have to be swapped out to hard disk as soon as the main memory is exhausted. You should try to profile it but I guess that takes at least 100 times longer than the one string comparision to test if you found the password.

Lets assume you have searched 99,9% of all possible passwords and so practically all passwords you generate were already tried (the worst case). Then avoiding the password comparision would be making your program just 1% slower. And that doesn't even take into account that you could eliminate the hash which would certainly give a speedup of more than the 1% you lost

2) Now I guess you made this as a test case and had a real encryption in mind so that testing the password means applying a costly function with permutations and math operations. But then the big search space becomes a problem. With 4 character passwords (and about 70 different characters) you have a search space of 24 million, with 5 characters 1.68 billion...

Leaving aside that perl hashes use a lot of memory and hashes are only efficient when they are mostly empty, you get to the limits of your memory very fast even if you use a more efficient hash storage. If you put the hash on disk instead of into memory you can store passwords with not even two characters more but then testing for doubles costs more than testing the password which makes it absolutely useless again.