Вот ещё интересная заметка на эту тему. Там тормоза добавлялись гипервизором в облаке
https://medium.com/appian-engineering/yet-another-reason-your-docker-containers-may-be-slow-on-ec2-clock-gettime-gettimeofday-and-9d92f6892048
xen использовал сискол для получения времени в миллисекундах, а kvm - не использовал. В результате на xen  тормозило из-за seccomp,  а на kvm - нет, т.к. не было сискола.

Ты "локально" тестировал, или в облаке под гипервизором?

Локально, на убунте в качестве хоста )

Не исключаю, что питон может внутрях себя получать время для каких-то внутренних таймингов. И если это выливается в сискол, то seccomp может реально аффектить это всё

В примере кода с medium можно предположить, что в случае оптимального использования numpy, основное время программа проводит внутри С-шного кода numpy и потому питон не посылает какие-то скрытые сисколы. Если же переделать на питонячий цикл, то у питона появляется возможность делать своё "грязное дело".

А какие есть тулзы, которые могут сгенерить FlameGraph, на котором будет видно сисколы? В питонячих версиях я такого вроде не видел. Там в основном только питонячий код показывается.

Есть утилитка perf

Но ее надо дополнительным скриптом в flame graph преобразовывать

Погонял примитивный скрипт который много раз октрывает файл, пишет туда один байт, закрывает. И ещё дёргает time.time() много раз (но это наверное не сискол).
В дефолтном контейнере выполняется 15-16 секунд. На хосте этот же скрипт работает 10 секунд. В контейнере с отключеным seccomp даже быстрее - 9 сек.

А ведь нет, оказалось что при использовании только time.time() гораздо больше просадка получается с seccomp, чем только от работы с файлом. Как раз вот те 1.5 раза это из-за time.time(). Если его убрать и оставить только файл, то разница всего 9 - 8 = 1 сек.

Лучше наверное

python -m timeit

засекать😊

Офигеть ты любопытный, прям круто ))

Но получается что при включенном seccomp оверхед в любом случае будет, а разрешен сисколл или запрещен не важно?

Википедия:

Фильтр запускается каждый раз, когда процесс совершает системный вызов. При запуске фильтр получает на вход структуру с данными о номере системного вызова, архитектуре, текущем состоянии счётчика команд и аргументах вызова[7][8]. Фильтр обязательно должен возвратить 32-битное значение, в котором верхние 16 бит содержат код действия, которое будет произведено, а нижние 16 бит содержат данные. Если в алгоритме фильтра по ошибке не предусмотрен возврат значения, то он не пройдет статический анализ и такой фильтр присоединён не будет[9].

В случае с time.time() в реальности проблема может быть не в нём, а в том что пришлось сделать сильно больше циклов, что бы в нормальном режиме скрипт выполнялся 10 секунд. С файлами таких циклов надо меньше.

💭 Исполняющий обязанности бота информирует:

Albert , у нас принято представляться и кратко рассказывать о себе с тэгом #whois.

Cпасибо за внимание!

python 4 потеснит эликсир?

А почему time.time()? Он ведь берет именно системное время, а оно может изредка внезапно меняться (мы сталкивались в лабе с 200+ машинами). Поэтому только timeit.default_timer(), и ничего более.

Но ведь timeit.default_timer это просто time.perf_counter 😊

"Один очевидный способ сделать что-либо" (с) 😂😂

дай угадаю: ты не голландец?

Хм. Действительно