Balancing Memory Usage vs Performance?

TwistedTR writes "I work for a company currently developing an application to run in an environment with a very small sum of available memory (sub 6 megs). My boss and I are in disagreement over speed vs memory overhead. He feels that speed is 100% key reguardless of the memory overhead required to meet it. The application is very math intensive so the more lookup tables we pre-generate at load time the faster the overall application runs. However, my boss is having me take us dangerously to the point where our target environment is going to run out of memory. The application makes use of user inputted data, and if the user so chooses it can be a WHOLE lot of data, which also uses a decent chunk of memory. My boss will not fold on my request to sacrifice some speed to prevent a possible fatal memory fill up. Has anyone out there had experience in dealing with developing in a simmilar situation, and if so do you have any ideas of how to balance performance vs memory on such a restrictive environment?"

Comments

Memory isn't always fast

[redelm]

Your boss is right in wanting speed. And I'd certainly use more memory if it got me speed. RAM is cheap, and users don't mind getting more if their problem gets bigger. That's a predicatable consequence.

The real issue becomes that LUTs aren't always fast. And bigger ones are slower because of the lower probability of a cache hit. DRAM has horrible latency, 120-180ns that corresponds to 120-360 CPU clocks. You can do alot of calcs in that time! Also the LUT can flood out cache to incur more cache misses.

I hope you are not right about big user data being fatal. It should never be. The pgm might get into swapping or thrashing and run real slow, but crashing is not acceptable. And how does your pgm perform when swapping? It will always be slower, but some go into light swapping while other pgms get into heavy thrashing.