在有些情况下，限制你的应用程序的因素是 RAM 而不是ROM。在这些情况下，你想要降低对于全局变量、堆和栈的依赖。这些优化由程序员来做比用编译器来做会更好。
由于 ROM 通常比RAM 更加便宜(以每字节为基准)，所以一个可接受的降低全局数据量的策略是把常数移到ROM 中去。如果你用关键字const 声明所有的常数，那么这可以由编译器自动完成。大部分的C/C++编译器把所有它们遇到的常全局数据放入一个特殊的数据段里，这个数据段可以被定位器识别为可分配ROM 的数据段。如果有很多的字符串和导向表数据在运行的时候不发生变化，那么这项技术是最有价值的。
如果有些数据一旦程序运行起来就固定了，但不一定是不变的，那么常数数据段可以改放在一个tb混合存储设备中。然后，这个存贮设备可以通过网络来更新，或者由一个指派的技术员来完成这个改变。在你的产品要部署的每一个地区的税率就是这种数据的一个例子。如果税率发生了改变，那么存储设备可以更新，但是同时也节省了附加的RAM。
减小栈的大小也可以降低你的程序对于 RAM 的需要。有一种方法可以准确地计算出你需要多大的栈。做法是用一个特殊的数据类型填满整个为栈保留的存储区域。然后，在软件运行一段时间之后——最好在正常和紧张两种情况下都运行一下——用调试工具研究被修改过的栈。有一部分仍然包含有你的特殊类型数据的栈存储区，因此可以安全地从栈的大小中减去那部分存储区的大小(注1)。
如果你在使用一个实时的操作系统，就要特别当心栈的大小。大部分操作系
——————————————————————————————————
注1：当然，你可能想在栈中留一点额外的空间——万一你的测试没有持续足够长的时间，或者没有准确地反映所有可能的运行场景。千万不要忘记栈的溢出对于你的软件来说是一个潜在的致命事件，要不惜一切代价避免。
统为每一个任务创建一个分离的栈。这些栈用于函数的调用以及在一个任务的设备场景中遇到的中断服务倒程。你可以通过前面介绍的方式为每一个任务的栈决定其数量。你可以设法减少任务的数量或者切换到一个操作系统，这个操作系统具有分离的为执行所有中断服务例程而建立的“中断栈”。后一种方法可以显著地降低每个任务对栈大小的要求。
堆的大小受限于 RAM 在所有的全局数据和栈空间都分配以后剩余的数量，如果堆太小，你的tbw程序就不能够在需要的时候分配内存，因此在废弃它之前一定要把malloc 和new 的结果和NULL 比较。如果你试过了所有这些建议，而且你的程序仍然需要太多的存储空间，那么你除了完全删除所有的堆之外没有别的选择。