|There's more than one way to do things|
Your questions don't have enough information to be able to give good answers. As asked, the best answers I can give you are:
how many entries i can store in hash table.
All of them, unless you run out of memory.
what is the performance if i store the more than 50 thousand records
It depends on what you're measuring.Uh, how do you define performance? Normally people talk about time when they talk about performance, but it's by no means the only one available.
Having given you some useless answers, here are
As has been mentioned earlier in the thread, a hash table is limited by the amount of memory you have. (Disk space in some cases, since virtual memory will let you spill over to the disk drive.) The OS will consume some of your memory, and perl doesn't store all the items in a hash table all packed together. Generally, when I'm estimating, I find that if the number of items I want to store times the size of the items is more than 1/5 of my RAM, then I start to worry about it. Otherwise, I don't even think about it.
Regarding performance, I find that it's rarely worth the time to discuss the performance of a language feature. Computers are so fast now, that even slow horrible algorithms are often just fine. Normally I think about performance only if I have actual code that performs too slowly to meet requirements. Then I don't worry about guessing, it's time to measure the code to find out where it's slow. Once you do that, that's the time to start asking questions about the performance of certain code constructs.
...who has been a little snarkier than usual lately, possibly as a result of having to switch to these consarned bifocals!