Прерывание процесса наверняка операционкой. Увеличь размер данных раз в 1000 - будет меньше прыгать.
On Mon, Feb 9, 2015, 16:42 Михаил Монашёв <[email protected]> wrote: > Здравствуйте, Alexander. > > >> Вот и ноду обогнали :-) > > > Ну это не совсем честно, ИМХО. Да и посмотри, как сильно читаемость > > кода ухудшилась! > > > Переписал через слайсы, чтобы перейти в цикле к сравнению с нулём (что > > намного быстрее): https://play.golang.org/p/SZYYqGDmQY и стало 11ms. > > Кстати, что странно, время выполнения этого кода прыгает иногда в 2 > раза. И профайлер VTune показывает в таких случаях очень большой Spin > Time: > > Elapsed Time: 0.382s > Total Thread Count: 5 > Paused Time: 0s > CPU Time: 0.063s > Spin Time: 0.011s <--- почти столько же, сколько работает > наше суммирование > Overhead Time: 0s > Effective Time: 0.052s > Idle: 0.000s > Poor: 0.052s > Ok: 0s > Ideal: 0s > Over: 0s > > Top Hotspots > Function CPU Time > runtime.memclr 0.026s <--- это освобождение памяти после окончания > работы > main.main 0.017s <--- это выделение памяти и заполнение массива > первичными данными > WaitForSingleObject 0.011s <--- это какие-то непонятные локи в > kernel32.dll > main.func╥001 0.009s <---- это код, работающий в горутине, который > мы собственно и замеряем > > Есть мысли, что это и как избегать? > > -- > С уважением, > Михаил mailto:[email protected] > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
