If you had a working product that was slow and memory hungry.
What would decide to do between these 2 options and why?
Couple of questions :
If answer to the first question is "the new server will not be powerful enough in one year", you'll have to optimize your application.
If answer to the "how much does it cost" is really much... Well, I let you guess what I'm thiking ;-) All depends on the answer to the previous point.
Without knowing the answer to that question, it'll be quite hard to help you.
My suggestion would be : optimize whatever you can, without rewritting -- this will at least get you some time ; you'll be able to think without being in rush, then.
This will allow you to do a better rewrite, and the resulting application will be far better -- and will probably scale better, which is really important if you think you'll have more users.
So :
I'd take #1 because I can guarantee you that #2 would actually end up taking longer and costing at least 5 times more then you think :-)
I vote 2, simply because a year from now, when your product is more heavily used, crunches more data, and requires more resources, you'll not be wanting to buy a bigger server yet again.
And there could come a time where where it isn't possible to get bigger hardware.
Since the price for both is the same (how about time ?) i would fix/develop (2) because you'll have more control over your sw. On the other hand since most programmers underestimate development time and costs this might it might be illusionary to fix the thing in time.
As you are implying that the cost is the same then a next thing to consider is the time to deliver.
1 Can probably be implement in a shorter time than 2 (If the cost of building 2 is 5 or 6 digits then it will be a significant time).
There would also be a benefit in getting the project in earlier.
Agaist this if you expect to enhance the system in future and it have a long life then improving the product could cut maintainence costs.
Profile it and rewrite or update the slower sections (bottlenecks). Do not rewrite the entire code base. This approach should get you the best bang for the buck while solving your challenges.
It has to be number 2 because you are only deferring any issues until you run out of money.
Saying that, what's the bottleneck? Quick fixes:
Hardware changes have a mostly linear benefit. If you can really ride the Moore law, the it can be almost exponential, for a while. Eventually you hit a non-Moore factor (like buget, or cooling requirements) and drop to linear.
Rewriting, if done well, will change the behavior, not just the performance. If your current software has geometric behavior (like O(n^2)), you'll need geometrically better hardware as you grow. If you get linear behavior (like O(n)), you'll have a lot more headroom to grow.
As is usually the case "it depends". Usually, a business owner will move in the direction of maximizing profit, but only after careful risk and impact analysis. The correct decision is influenced heavily by a number of factors:
What minimizes cost? A 6-digit mainframe may not be less expensive than the 6-digit development effort to re-write existing code.
How much improvement do you need? For most CPU and memory bound applications, you can't really expect a speedup of more than 5x simply by throwing more hardware at the problem. For certain classes of problems, well-written data structures and algorithms can improve the runtime of an application literally millions of times faster.
What minimizes risk? Re-writing legacy code is a guaranteed, time-tested, proven way to write new bugs into existing software.
How much scalability do you need? Some computations can be written in a way that small parts of the computation can be distributed across multiple servers, effectively allowing you to scale computations linearly by adding more hardware. It takes careful planning to write software in this way --- and if scalability wasn't part of the game plan from the very beginning, then almost certainly you'll need to re-write your code.
There's no good answer to your question without knowing more about your individual situation.
If this is an in-house application, then go with option 1. The costs are the same for both options, but you get your app in place now. Meanwhile, hardware costs keep going down; soon your 5-6 digit server is going to be a 4-digit server.
If it's something you ship to users, option 2 sounds more credible, but it depends on how quickly you need to ship, versus how much your users are willing to spend on server equipment.
Depends on where the bottlenecks are. I wouldn't make this decision without knowing that first. Faster, better equipment may not solve your problem if the problem is poor design or badly written queries and then where are you after having spent the whole budget?
Not black or white, one or two. I think you should optimize where you find low hanging fruits and buy hardware where the optimization is hard. You should not choose, but find the balance.
I tend to favor alternative 2, partly because I think it is fun, partly because there might be other good side effects, like better response times.
You should also consider your architecture if you can distribute your application on many servers, then you might cope with two cheap servers instead of one really expensive.