《内存受限系统》由会员分享，可在线阅读，更多相关《内存受限系统（37页珍藏版）》请在金锄头文库上搜索。
1、 Thinking Small The Processes for Creating Small Memory Software 2004 Charles Weir, James Noble. Abstract: This paper describes some process patterns for teams to follow when creating software to run in limited memory. It is a draft version of a chapter to add to the authors book Small Memory Softwa
2、re, and follows the structure of other chapters in that book. Major Technique: Thinking Small A.k.a Small methodology, Real programming. How should you approach a small system? Youre developing a system that will be memory-constrained. There are many competing constraints to satisfy If different dev
3、elopers take different views on which things to optimise, they will produce an inconsistent system that satisfies none of the constraints. Youre working on a project and you suspect there will be resource limitations in the target system. For example, the developers of the Super-spy 007 version for
4、the Strap-it-On wrist-mounted computer face a system with only 200 Kb of RAM and 2 Mb ROM. How are they to adjudicate the demands of the voice recognition software, the vocabularies and the software-based radio, to make it a secret agents dream toy? Should they store the vocabularies in ROM to save
5、RAM space, or keep them in RAM to allow them to change from Russian to Arabic on the fly? What, in short, is important in their system, and what is less so? In many projects its clear from the outset that the development team will have to spend at least some time and effort satisfying the systems me
6、mory limitations. You have to cut your coat to fit your cloth. Yet if the team just spends lots of effort optimising everything to work in very limited memory, theyll waste a lot of time or maybe produce a product that could have been much better. Worse still the product may fail to work at all beca
7、use they have been optimising the wrong thing. For example, any of the following facilities may be limited: Heap (RAM) space for the whole system Heap space for individual processes (if the maximum heap size of a process is fixed) Process stack size Secondary storage use ROM space (for programs that
8、 execute from ROM) Optimising one of these will often be at a cost from one of the others. In addition techniques that optimise memory use will tend to compromise time-performance, usability or both. In any system the architects will have to moderate the demands of different components in the system
9、 against each other. That is a big and highly sensitive task. Thinking Small The Processes for Creating Small Memory Software Weir, Noble 2004 Charles Weir, James Noble Page 2 Software programmers tend to take their design decisions seriously, so capricious decisions can cause friction or worse with
10、in a development team. You might hope to use clever techniques to defer the key decisions about these priorities until later in the project, when youll know more about the implementation. But in practice many of the most important strategic decisions cannot be deferred, as they pervade the entire sy
11、stem and provide a framework for later decisions. Such strategic decisions are reflected, for example, in the interfaces between components, in the trade-off between ROM and RAM, and in the question of whether or not to use Partial Failure in components. Design decisions about the trade-offs based o
12、n just individual designers foibles, on gut feel or on who shouts loudest will lead neither to consistent successful designs, nor to a harmonious development. Youll need a more objective approach. Therefore: Devise a memory strategy for the entire project. First draw up a crude MEMORY BUDGET of the
13、likely available resources in each of the categories above. If the figures are flexible (for example, if the system is to run on standard PCs with variable configurations and other applications), then estimate or negotiate target values with clients. Meanwhile, also estimate very approximately the l
14、ikely memory needs of the system youre developing. Identify the tensions between the two. Identify the design decisions that will significantly challenge the memory use, and ensure these decisions happen early. Based on this comparison youll be in a position to identify which constraints are most vi
15、tal. It may be a constraint on one of the forms of memory in the system. Other constraints time constraints, reliability, usability may also be as or more important. Enshrine these priorities as a core given for everyone working on the project. Ensure that absolutely everyone working on the team und
16、erstands the priorities. Write the strategy in a document; make presentations; distribute the T-shirt! Indoctrinate each new developer who joins the team afterwards with the same priorities. Once youve identified your priorities, youll be in a position to plan how to approach the rest of the project. You may need a formal MEMORY BUDGET, or perhaps MEMORY TRACKING. Or you may choose to leave MEMORY OPTIMISATION until near the end of the p
