Slashdot Mirror
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?"
You want to make the lookup tables dynamic in the sense that you may deallocate them when you run out of memory. At the expense of a conditional statement, you have fast lookups... until you run out of memory and at this point you explicitly calculate everything.
Easy.
I'm tired of these questions.
* The tone is almost always a bit whining
* The "facts" are presented by one of the parties only, and I bet they have been coloured by personal views most of the time
Interestingly enough, though, the high number of post about evil and/or stupid managers lead me to believe that the power distance between manager and knowledge workers might be a bit too large in the posters countries.
I'm a developer myself, and I find that my managers listen to me, and I can't recall a situation where I have explicitly been told to do something. I things were different I'd find another job - simple.
You seem to have two main issues here. The first is that a person with (assumedly) less technical competance than you is dictating technical policy; and the second is that the usage of this application is too dynamic to allow for what your boss wants to do.
You need to establish how technically competant you are compared to your boss. Can you resort to hard technical fact to prove your case? Can you show that the speed sacrifice is negligable? If it is not, can you justify it?
The last point is important: if speed is so important (and you have to conceed that your boss is more driven by customer requirements than you are) then maybe you need to compromise on some other aspect.
It is already clear that, although customers can enter any amount of data, they can't enter 6Mb, because there are no enough resources. What about 4 Mb? 2Mb? How much is too much. Decide on a reasonable upper limit for customer data, and work from there. On a system with the limitations you have, this should have been part of the design spec.
Once you have determined an upper limit for customer data, you can calculate how much memory you have permanently available. It may be possible (depending on your app) to use additional memory when the customer supplies less data.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
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.