程序局部性原理感悟

局部性原理
  程序的局部性原理是指程序在执行时呈现出局部性规律,即在一段时间内,整个程序的执行仅限于程序中的某一部分。相应地,执行所访问的存储空间也局限于某个内存区域。
  局部性原理又表现为:时间局部性和空间局部性。
  时间局部性是指如果程序中的某条指令一旦执行,则不久之后该指令可能再次被执行;如果某数据被访问,则不久之后该数据可能再次被访问。
  空间局部性是指一旦程序访问了某个存储单元,则不久之后。其附近的存储单元也将被访问。
  这一规律是是普遍事实的总结,更是许多计算机技术的前提假设,比如.NET中托管堆以及代龄的处理过程,便是基于这个认识。
  之所以有这个规律,很多人认为原因是:程序的指令大部分时间是顺序执行的,而且程序的集合,如数组等各种数据结构是连续存放的。对于这一点,我个人表示赞同。
  程序的局部性原理是如此重要,以至于与程序设计的各个方面都存在密切的关系。
 
局部性与效率
  熟悉代码的局部性原理,并且按照这个思路去写代码,可以显著的提高代码的执行效率,先看下面的C#代码:
static void Main(string[] args)
{
 int[,] a = new int[10000,10000];
 int sum = 0;
 // 按照先行后列的顺序遍历二维数组,这是正常做法
 WriteTimes(() =>
 {
  for (int i = 0; i < 10000; i++)
  {
   for (int j = 0; j < 10000; j++)
   {
    sum += a[i, j];
   }
  }
 });
 // 按照先列后行的顺序遍历二维数组,这是异常做法
 WriteTimes(() =>
 {
  for (int j = 0; j < 10000; j++)
  {
   for (int i = 0; i < 10000; i++)
   {
    sum += a[i, j];
   }
  }
 });
 
 Console.Read();
}
 
static void WriteTimes(Action func)
{
 DateTime dt0 = DateTime.Now;
 func();
 DateTime dt1 = DateTime.Now;
 Console.WriteLine((dt1 - dt0).Milliseconds);
}

  大家可以输出一下,在我的机器上的输出为(具体的数值可能不同,但是大小比例应该差不多):

102
999

  这个例子本身并没什么实际的意义,但如果处理的数据量足够大,并且可能需要频繁的在外存、内存、缓存间调度,又注重效率的话,这个问题就有可能会被陡然放大了。不过,通常来说,效率总是在程序出现性能问题后才应该被关注的方面

 
局部性与缓存
  归根结底,缓存(各种缓存技术,CPU缓存,数据库缓存,服务器缓存)探讨的也基本都是效率的问题,看另一个来源于网上某位仁兄的问题:
// 写法一:循环内塞进好几件事
for (int i = 0; i < 1000; i++)
{
 WriteIntArray();
 WriteStringArray();
}
// 写法二:循环内只干一件事
for (int i = 0; i < 1000; i++)
{
 WriteIntArray();
}
for (int i = 0; i < 1000; i++)
{
 WriteStringArray();
}

问:两种写法哪个好?

  有的同学认为写法一效率高,因为循环只执行了一遍,而有的同学认为写法二效率高,因为该写法中每个循环内的局部变量大部分情况下是比写法一少,这样更容易利用CPU的寄存器以及各级缓存,这满足局部性原理,所以效率较好。
  我写了简单的程序验证了一下,发现确实有时候写法一执行时间较短,有时候写法二执行之间较短,没有明显的固定规律,所以我认为这里的效率一说不太明显,当然了也许是这里的循环次数比较少,循环多次的低效还没有体现出来,感兴趣的可以自己试一下大的循环。
  即使是这样的结果,我还是倾向于使用第二种写法,这不是效率的原因,而是重构中,提倡一个循环只干一件事。
 
局部性与重构
  重构的基本原理这里就不多说了,感兴趣的随便搜一下就可以了。重构的基本原则中就有诸如:一个循环只干好一件事,关联性强的代码放到一起,变量定义在使用的地方等等。这些原则与局部性原理阐述的规律竟然是如出一辙。
  看一些我认可的写法:
// 一个循环内只干好一件事
for (int i = 0; i < 1000; i++)
{
 WriteIntArray();
}
for (int i = 0; i < 1000; i++)
{
 WriteStringArray();
}
 
// 原始的代码
List<int> salaryList = new List<int>();
List<int> levelList = new List<int>();
List<int> scoreList = new List<int>();
 
collectHighSalary(salaryList);
collectHighLevel(levelList);
collectHighScore(scoreList);
 
collectMiddleSalary(salaryList);
collectMiddleLevel(levelList);
 
collectLowSalary(salaryList);
collectLowlevel(levelList);
// 重构成:
// 有关系的代码放到一起
// 变量需要时再定义
List<int> salaryList = new List<int>();
collectHighSalary(salaryList);
collectMiddleSalary(salaryList);
collectLowSalary(salaryList);
 
List<int> levelList = new List<int>();
collectHighLevel(levelList);
collectMiddleLevel(levelList);
collectLowlevel(levelList);
 
List<int> scoreList = new List<int>();
collectHighScore(scoreList);  

  局部性原理不仅与语句和函数的组织方式息息相关,还与组件的组织方式互相呼应。

 
局部性与高内聚
  从元素(函数,对象,组件,乃至服务)设计的角度,内聚性是描述一个元素的成员之间关联性强弱尺度。如果一个元素具有很多紧密相关的成员,而且它们有机的结合在一起去完成有限的相关功能,那这个元素通常就是高度内聚的。高内聚的设计是一种良好的设计。
  耦合性从另一个角度描述了元素之间的关联性强弱。元素之间联系越紧密,其耦合性就越强,元素的独立性则越差,元素间耦合的高低取决于元素间接口的复杂性,调用的方式以及传递的信息。低耦合的设计是一种良好的设计。
  一个具有低内聚,高耦合的元素会执行许多互不相关的逻辑,或者完成太多的功能,这样的元素难于理解、难于重用、难于维护,常常导致系统脆弱,常常受到变化带来的困扰。
  毫无疑问,遵循良好的局部性原理通常能得到良好的高内聚低耦合元素,反之,代码中元素的高内聚低耦合也使的局部性得以大大加强,此所谓相得益彰。
 
局部性与命名
  说到命名,不得不提著名的匈牙利命名法。
  在我读了《软件随想录:程序员部落酋长Joel谈软件》一书之前,我认为的匈牙利命名法则就是在驼峰式命名的基础上,在变量名前加上变量的类型,例如iLength表示int型的表示长度的变量。
  但是在我阅读了《软件随想录》一书相关的章节以后,才彻底的了解到其中的误解。原来微软那位大牛推荐的匈牙利命名法居然不是我想的那样。
  在该书中,作者将匈牙利命名法分为两种,流行的并且被废掉的叫“系统型匈牙利命名法则”,这种命名法将变量类型加到了变量名字前面,老实说确实没什么意义,特别是在现代编辑器中。
  事实上,微软那位仁兄推荐的是叫做“应用型匈牙利命名法则”的规则,那就是把变量的应用场景加到变量的名字前面
  比如在页面开发中,直接从用户输入得到的Name字符串可以起名叫:usName,其中us代表unsafe,意思是这个字符串是用户输入的,没用经过编码处理,可能是不安全的。而经过编码的Name字符串可以起名叫sName,其中s代表safe,意思是这个字符串经过了编码处理,是安全的。
  谈到命名的规则,就是为了说明下面这个息息相关的问题:代码错误检查。
  代码错误检查也是一个经典的话题,如何让代码的错误提前暴露出来,而不是发布后由客户去发现,这是个问题。
  满足局部性原理,使得我们的程序内聚性通常很好,但是毫无疑问,有些元素还是必须要贯穿很多的行的,比如在某些函数中,定义变量和末次使用变量的地方可能相差几十行:
var usName = getName();
action1(usName);
// 此处省略20行...
sName = usName;
// 此处省略10行...
document.write(sName);

  我不得不承认,Joel老兄提出的“应用型匈牙利命名法则”还是相当有作用的。比如中间那行:

sName = usName;

  我们很容易就会从变量名发现这行代码存在安全性威胁。

 
我们其实生活在世界的局部中
  推而广之,局部性原理不仅仅是适用于程序的理论,而是适用于我们生活的各个方面的重要规律,它的称呼向来随着场合的不同而有所变化,比如有时叫“习惯”,有时叫“惯性”,有时又演化成“熟悉的人/事”等。总之,我个人认为,人总是倾向于在局部的、连续的时间空间内做相关的、熟悉的事情,程序其实是人类做事风格的反应。
posted @ 2014-12-30 18:24  沙场秋点兵  阅读(2602)  评论(2编辑  收藏