Performance 在按包含时间列表排序的基础上有一个简单的递增时钟程序！优化netlogo代码

在我的模拟中，在解决了一些其他性能问题后，每个滴答时钟值应该增加1，我注意到此函数位于按包含时间排序的列表顶部（值为960205 ms）：

呼叫包括T（ms）不包括T（ms）不包括/呼叫

40001960205.4513586.5910.090

to increment-clock  
         set clock (clock + 1)
                   if clock = 48
                         [ set clock 0 ]
    end

据 Inclusive time是从输入过程到完成的时间

我觉得这个应该是直截了当和简单的

我做错了什么

我记得我以前用滴答声来增加时钟，我不记得为什么我把它改成了我上面提到的那个，但这应该不会花这么多时间！（此事件的探查器包含时间值为599841.851 ms，表明以下事件比上述事件快：

to increment-clock  
         set clock (clock + 1)
                   if ticks mod 48 = 0 [set clock 0]
end

呼叫包括T（ms）不包括T（ms）不包括/呼叫

40001599841.8512943.394 0.074

谢谢。

---

Marzy

这一定是探查器扩展中的一个错误。至少，我想不出其他解释。（好吧，你是在运行之间调用

profiler:reset

？）

我刚才试过这个：

extensions [profiler]

globals [clock]

to increment-clock  
         set clock (clock + 1)
                   if clock = 48
                         [ set clock 0 ]
    end

to test
  profiler:reset
  profiler:start
  repeat 1000000 [ increment-clock ]
  profiler:stop
  print profiler:report
end

我得到：

observer> test
BEGIN PROFILING DUMP
Sorted by Exclusive Time
Name                               Calls Incl T(ms) Excl T(ms) Excl/calls
INCREMENT-CLOCK                  1000000   1176.245   1176.245      0.001

Sorted by Inclusive Time
INCREMENT-CLOCK                  1000000   1176.245   1176.245      0.001

Sorted by Number of Calls
INCREMENT-CLOCK                  1000000   1176.245   1176.245      0.001
END PROFILING DUMP

这似乎更合理

---

您可以在或处报告此错误bugs@ccl.northwestern.edu.

我用同一个随机种子进行了实验，改变了到增量时钟程序，并打印了配置文件结果。我知道这可能不是衡量两个函数性能的好方法，但我认为在两个类似函数中选择一个函数可能是好的nsI在我的Go过程中调用了这个方法，我没有单独检查它（像你一样），是的，我在运行之间重置了探查器，它一定是一个错误，因为即使我更改了许多其他内容，它仍然在我的列表的顶部！