为什么程序空间是成本问题？
- 直接成本: 除了运行时间, 程序占据的空间也是主要开销;
- 算例: IBM APL 交互式系统月租 400 美元, 至少占 160K 字节内存; Model 165 上内存租金约 12 美元/千字节/月, 全时可用则内存租用费 1920 美元/月;
- 常见误判: 批评"2M 内存的机器上操作系统占用 400K"就像批评波音 747 耗资两千七百万美元一样无知--必须先问"它能干什么";
- 正确判断: 应整体评价, 比较同样的钱用在硬件、程序员、应用上哪个更有效;
- 结论: 规模本身不是坏事, 不必要的规模不可取;
规模控制为什么既是技术工作也是管理工作？
- 项目经理的职责: 研究用户和应用以设置系统规模, 把系统划分成部分并设定每部分的规模目标;
- 技巧性: 规模-速度权衡方案的结果在很大范围内变化, 设置目标需要对每个可用方案有深刻了解;
- 预留: 聪明的项目经理会给自己预留一些空间, 在工作推进时分配;
- 类比: 就像硬件开发人员设立元器件数量目标、控制数量、想出减少零件的方法;
OS/360 在规模控制上得到哪些教训？
- 教训一（预算范围）: 仅对核心程序设定规模目标不够, 必须把所有方面都编入预算;
- 具体表现: 没有同时设置访问目标; 程序员发现核心超标后把代码分解成链接库, 反而增加整体规模、降低速度, 而管理控制系统既没度量也没捕获;
- 后果: 性能仿真程序首次运行显示 Fortran H 在 Model 65 上每分钟只模拟编译 5 条语句, 频繁磁盘访问近似页面切换;
- 教训二（功能与规模绑定）: 在指明模块有多大的同时, 必须确切定义模块的功能;
- 具体表现: 按规模分配功能后, 碰到规模问题的程序员把代码扔给别人, 控制程序管理的缓冲区变成用户空间的一部分, 破坏系统稳定和安全性;
- 教训三（全局视角）: 项目规模大、缺乏管理和沟通时, 每个人以为自己是"争取小红花的学生"而非构建系统产品的人员, 于是局部优化;
- 结论: 系统结构师必须持续保持警觉, 确保连贯的系统完整性; 培养开发人员从系统整体出发、面向用户的态度, 是管理人员最重要的职能;
有哪些减少规模的技能？
- 技能一（用功能交换尺寸）: 决定用户可选项目的粗细程度;
- 分组原理: 把若干选项合并成整组标价时, 程序所需空间更少, 如同汽车把照明灯、点烟器和时钟作为整个配件;
- 内存受限的后果: 最小功能模块的适用范围难以推广, 因为模块尺寸由系统主干占用空间决定;
- 反向代价: 很难用为小型系统设计的模块构造出高效的大型系统, 因为模块规模本身带来空间和速度损失;
- 技能二（空间-时间折衷）: 对给定功能, 空间越多速度越快, 这一点在很大范围内适用, 也正是规模预算得以成立的前提;
- 技能三（公共库）: 每个项目要有队列、搜索和排序的例程或宏库;
- 双版本: 库中每个组件至少应有两个实现--运行速度较快和短小精炼的（20 年后作者认为这一条已有些过时）;
- 并行性: 公共库开发是一件重要的实现工作, 可与系统设计并行进行;
项目经理怎样帮助团队取得良好的空间-时间折衷？
- 培训: 确保团队在编程技能上得到培训, 而不是只依赖自己掌握的知识和先前经验;
- 特别强调: 使用新语言或新机器时培训尤其重要, 熟练使用需要快速学习和经验广泛共享;
- 激励: 新技术的学习和应用也许应伴随特别奖励或表扬;
- 投资积累: 认识到编程需要技术积累, 需要开发很多公共单元构件;
- 20 年后的修正: 临时空间尺寸和磁盘访问数量这一决策整体已显得过时, 起因是虚拟内存, 后来是成本低廉的内存; 现在用户通常购买能容纳主要应用程序全部代码的内存;