Cache invalidation is one of the hardest problems in computer science. Tread lightly here.
Performance is a very popular way to waste time playing with working code rather than move on to new challenges. Tread lightly here.
That said, if you have access to a good hashing data structure that you could test for previously converted numbers before converting you might be able to see some gains. It really depends on the usage. CPU's are fast and memory fetches are slow so don't expect this to pay off in every case. You're betting that the hash lookup will take less time than the conversion. You're betting that the hash look up will succeed often enough to save more time then is lost when it fails.
If you're into Big O it's easy to jump on this saying O(1) is better than O(n) but keep in mind in the real world n can be small making Big O meaningless.
Also understand that this is a space time trade off. Even if you can make this faster that doesn't mean you got that speed for free. CPU cycles are a limited resource but so is memory. This is going to cost memory. Think about how many numbers you're going to allow this thing to hash. If users get to decide these numbers think about what a hacker can now do to your memory foot print.
Even if you're confident that you have a winner because your math and performance tests say this is the way to go you can deploy only to find out that something is different between your test and operational enviroments that is causing a difference in the number of cache misses. Which means the computer happened to leave the number you want in some slower memory. This is hard to test for, hard to predict, and can mess with your performance numbers.
Just trying to answer the question: "which is better?" can be considered over engineering. But if you have tests that show this is where most time is being spent and making it faster here truly is important it might be worth a try.
However, before you whip out that hash table make sure you've asked: "Why are we converting the same string over and over anyway?" It might be a problem you can solve with a little change to your architecture. If so then slapping this on would just be a kludge. Make sure you really need to do this before you invest to much in doing it.