<p dir="ltr">Прерывание процесса наверняка операционкой. Увеличь размер данных раз в 1000 - будет меньше прыгать.</p>
<br><div class="gmail_quote">On Mon, Feb 9, 2015, 16:42 Михаил Монашёв <<a href="mailto:postmaster@softsearch.ru">postmaster@softsearch.ru</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Здравствуйте, Alexander.<br>
<br>
>> Вот и ноду обогнали :-)<br>
<br>
> Ну это не совсем честно, ИМХО. Да и посмотри, как сильно читаемость<br>
> кода ухудшилась!<br>
<br>
> Переписал через слайсы, чтобы перейти в цикле к сравнению с нулём (что<br>
> намного быстрее): <a href="https://play.golang.org/p/SZYYqGDmQY" target="_blank">https://play.golang.org/p/<u></u>SZYYqGDmQY</a> и стало 11ms.<br>
<br>
Кстати, что странно, время выполнения этого кода прыгает иногда в 2<br>
раза. И профайлер VTune показывает в таких случаях очень большой Spin<br>
Time:<br>
<br>
Elapsed Time: 0.382s<br>
Total Thread Count: 5<br>
Paused Time: 0s<br>
CPU Time: 0.063s<br>
Spin Time: 0.011s <--- почти столько же, сколько работает наше суммирование<br>
Overhead Time: 0s<br>
Effective Time: 0.052s<br>
Idle: 0.000s<br>
Poor: 0.052s<br>
Ok: 0s<br>
Ideal: 0s<br>
Over: 0s<br>
<br>
Top Hotspots<br>
Function CPU Time<br>
runtime.memclr 0.026s <--- это освобождение памяти после окончания работы<br>
main.main 0.017s <--- это выделение памяти и заполнение массива первичными данными<br>
WaitForSingleObject 0.011s <--- это какие-то непонятные локи в kernel32.dll<br>
main.func╥001 0.009s <---- это код, работающий в горутине, который мы собственно и замеряем<br>
<br>
Есть мысли, что это и как избегать?<br>
<br>
--<br>
С уважением,<br>
Михаил mailto:<a href="mailto:postmaster@softsearch.ru" target="_blank">postmaster@softsearch.<u></u>ru</a><br>
<br>
--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
</blockquote></div>