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.
Prioritize the tables that you need to generate.
Do some profiling on a simulation to figure out how much memory it takes to accomodate certain amount of user data.
Based on your profiles, generate only as many tables as you can comfortably fit. Obviously, fit the most important, speed improving, tables first.
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
Suck it up, and do your job like you're told. If he's wrong, you'll all find out the hard way. If he's right, I bet you'll never follow up with us.
In essence I can second that. Doing IT support of all kind (from desktop support to setting up large scale WANs) I know customers do those things:
The computer must run all the time, but when they see the price for a full clustered shared RAID system, they suddenly can accept a downtime of 1 day (complete hardware failure).
They want to keep backup data for at least one year, but at the price of those SDLT taped, they tend to choke and cut it down a lot.
Fully redundant links (downtime is not acceptable), but in the end they choose a simple T1 (with service agreement for 99.x% uptime guarantee).
The point of those examples? Customers have wishes without the full knowledge of the consequences. Like the boss who thinks "Speed is everything". While it now is very convinient to say "My boss said so, I know it will fail, but he will be blamed." this does not work. Customers (and bosses) have dreams and wished, but it's up to us (engineers, programmers) to pull them down to Earth and explain them why it's a bad idea and how to compromise, so everyone is happy. So far, this worked very well for me. I bet this works for most bosses too.
PS: I know there are some bosses/customers/etc. who absolutely know better, no matter what you do. And the answer to the problem is: use look up tables to gain speed if there is memory available, drop them if memory gets tight, and do a graceful abort if memory is full. And limit the valid input to useable amounts by definition (Specs).
6 megs might be seen as some to be a small amount of memory. Please don't use up the adverb 'very' in this fashion, however. Many of us have coded in less than 100K of memory. Some of the smaller controllers (i.e. Motorola 6805s) have less than 128 bytes of Read/Write memory (and less than 2K of program memory) and are quite useful. Assembly language becomes necessary.
6 megs is one hell of a lot of memory. What kind of bloatware world have I fallen asleep and woken up to find myself in?