0

In my simulation every tick clock value should increment by one, after resolving some of my other performance problems I have noticed this function is on top of the sorted by inclusive time list (the value is 960205 ms):

Calls Incl T(ms) Excl T(ms) Excl/calls

40001 960205.451 3586.591 0.090

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

According to http://ccl.northwestern.edu/netlogo/5.0/docs/profiler.html Inclusive time is the time from when the procedure was entered, until it finishes

I thought this one should be straight forward and easy,

what I am doing wrong here?

I remember I used ticks before to increment the clock , I don't remember why I have changed it to the one I mentioned above, but still this should not take this much time! (the profiler inclusive time value for this one is 599841.851 ms which indicated following is faster than the one above:

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

Calls Incl T(ms) Excl T(ms) Excl/calls

40001 599841.851 2943.394 0.074

Thanks. Marzy

Marzy
  • 1,834
  • 14
  • 23
  • I have ran experiments with the same random seed with changing the to increment-clock procedures and printed the profile results. I know this might not be a good way to measure performance of two functions but I think it might be good for choosing one function among two similar functions – Marzy Nov 05 '13 at 04:13

1 Answers1

1

That has to be a bug in the profiler extension. At least, I can't think of another explanation. (Well, are you calling profiler:reset between runs...?)

I tried this just now:

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

and I get:

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

which seems much more reasonable.

You can report the bug at https://github.com/NetLogo/NetLogo/issues or bugs@ccl.northwestern.edu.

Seth Tisue
  • 28,052
  • 11
  • 78
  • 142
  • I call this method in my Go procedure and I did not check it individually (like yours), and yes I reset profiler between runs, it must be a bug because it's still on top of my list even when I changed many other things! – Marzy Nov 05 '13 at 13:03