“变量应该给出最小的范围”。真的吗?

时间:2017-03-17 02:05:50

标签: .net performance loops optimization timer

我多次阅读以下句子:

  

通常,变量的范围应最小。

请参阅以下方案中变量num的使用:

Private num As Integer
Private Sub Timer_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer.Tick
    'Your code where num is initialized and used
End Sub

或者:

Private Sub Timer_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer.Tick
     Dim num As Integer
     'Your code where num is initialized and used
End Sub

请记住,Timer_Tick是一个循环计时器,因此第一个场景中的num仅被声明一次,而在第二个场景中,每次计时器滴答时都会声明它。

第一种用法在代码执行速度方面是否真的不同?哪一个更有效率?关于这些例子,引用的句子在多大程度上正确地忽略了可读性偏好?

我相信如果代码中存在大量的迭代和循环,第二种情况会比第一种方案产生一些性能影响。

1 个答案:

答案 0 :(得分:0)

  

通常,变量的范围应最小。

我同意。

  

第一种用法在代码执行速度方面是否真的不同?

不仅仅是因为范围。

  

哪一个更有效率?

如果只是范围的问题,那么我希望它们编译成非常相似的CIL,如果不相同的话,那么没有区别。可能会有一些轻微的怪癖导致一个人轻微击败另一个,但是这样的怪癖可以走向任何一种方式。

在这种情况下,虽然范围的差异意味着没有类似的比较;方法之外的字段与本地内部的字段不同。通常,字段使用比本地更昂贵,但如果初始化需要只发生一次并且本身很昂贵,那么缓存(“memoisation”)可以得到回报。然而,这不仅仅是范围的差异。范围往往不会产生明显的性能影响,除非它隐藏的某些内容也使得它不像是一样(例如,捕获的本地与非捕获的本地不同)。

  

关于这些例子,引用的句子在多大程度上正确地忽略了可读性偏好?

所引用的句子都是关于可读性的事实以及您从允许使用范围中了解变量使用范围的事实。范围越紧,它就越能反映出意图,这就是人类可读代码应该努力的目标。

  

我相信如果代码中存在大量的迭代和循环,第二种情况会比第一种方案产生一些性能影响。

只是因为它不仅仅是在这里的范围,而且还有变量的类型。