LINUX.ORG.RU

Aннотирование исходного кода python отрицательно сказывается на времени запуска программ?

 


1

1

Всем привет! Объясните пожалуйста, кто в курсе последних фич в сообществе Python? Аннотирование исходного кода отрицательно сказывается на времени запуска программ на Python? Просто я это прочитал в документации What’s New In Python 3.7 — Python 3.7.4 documentation. И вообще стоит ли писать весь код аннотируя везде? Вы как относитесь к аннотациям в Python?

Deleted

Последнее исправление: Deleted (всего исправлений: 2)

Ответ на: комментарий от eternal_sorrow

ну я так понял, шо аннотации очень помогают для отладки кода, да и вообще удобно же для всяких ide. например:

my_var: str = input("Ну-ка сюда че напиши?")

# и вот здесь уже ide уже предпологает что он ожидает,
# и сразу же автодополняет строковые методы
print(my_var.uppercase())
Deleted
()
Ответ на: комментарий от eternal_sorrow

меня в первую очередь волнует производительность кода, насколько он будет нагружать процессор или ram компьютера? ты пробовал вообще играть с этими аннотациями?

Deleted
()

Использование скриптоты отрицательно сказывается на времени запуска программ.

Аннотированием по сравнению с этим можно пренебречь.

anonymous
()
Ответ на: комментарий от eternal_sorrow

У тебя есть какое-то опровержение тому факту, что итерпретатор питота стартует кардинально медленнее хелловорлдного бинаря?

А так я к тому, что оп заморачивается чушью.

anonymous
()
Ответ на: комментарий от eternal_sorrow

да, но не нет. интерпритатор то их игнорирует, но при «компиляции» в байткод они парсятся а также происходит валидация доступности заданных типов в скопе на этапе построения ast (и в случае чего будет выдана ошибка).

genryRar ★★
()
Ответ на: комментарий от Deleted

ну дык замерь, че.
насколько помню, импакт заметен только на больших файлах с кучей аннотаций - если разбито на небольшие модули, то пофиг.
хотя если используется новый режим парсинга аннтоаций из 3.7, то там думаю все иначе

genryRar ★★
()
Ответ на: комментарий от eternal_sorrow

вот тогда нет.

но это опять таки про «старый» режим аннотаций.

genryRar ★★
()
Ответ на: комментарий от anonymous

Использование скриптоты отрицательно сказывается на времени запуска программ.

Когда-то давно делал замеры времени запуска скриптов, выводящих просто строку «hello». Питон стартует (скрипт отрабатывает) примерно 500-1000 раз медленнее bash и perl. Bash на 10% быстрее perl. Кстати, python2 стартует быстрее чем python3, но долгий и сложный скрипт на python3 отрабатывает быстрее чем python2 (скрипт один и тот же).

anonymous
()
Ответ на: комментарий от anonymous

Чё-то не то ты мерил. Баш быстро стартует скрипты потому, что он уже в памяти, твой шелл. А питон стартует относительно медленно первый раз, потом также как и баш, но сам питон быстрее баша в несколько раз. Быстрее питона стартует и работает тока node.js и go, про сишку не говорю даже. В плане написания какой-либо бизнес логики для быстрого старта go идеален. Насчёт пёрла - он уже не нужен, не юзабелен.

menangen ★★★★★
()
Ответ на: комментарий от menangen

Да всё равно, можно повторить эксперимент с даш или чем-нибудь ещё. Баш конечно долго стартует, но зш (особенно с плагинами) ещё дольше, а питон запускается под 10 секунд (и да он уже вроде висит в памяти у какой-то программы и запускался перед этим). Разница будет только если его запускать подряд много раз, тогда огромная задержка лишь у первого запуска. Как по мне это огромный недостаток, особенно если посмотреть на си, которая динамически линкуется с полсотней либ и отрабатывает за какие-то наносекунды. И кроме того, большинство задач, где применим шелл, завершаются до того как питон только запустися и прочитает все свои файлы, вот это тоже проблема.

linuxnewbie
()

Сказывается отрицательно, но когда запускается готовый байт код, то разницы нет.

Octagon
()
Ответ на: комментарий от menangen

Чё-то не то ты мерил.

Сам измерь. К такому измерению подтолкнули тормоза при при отработке ./configure со своим враппером над компилятором. С враппером на питоне практически невозможно было дождаться ./configure. Результат измерения показал, что причина в долгом страте python. Враппер был переписан на перле из-за ущербности bash по сравнению с perl.

anonymous
()
Ответ на: комментарий от anonymous

Да не. У меня джанга с кучей модулей стартует 0.5 сек на hdd и готова к отдаче запросов, на ssd 0.1. Что там за configure хз, видимо, внешние процессы стартовала.

menangen ★★★★★
()
Ответ на: комментарий от menangen

Пишу код прямо здесь, возможно, есть ошибки

hello.py

#!/usr/bin/python
print("hello")

hello.pl

#!/usr/bin/perl
print "hello\n"
$ time for i in {1..1000}; do ./hello.pl; done
$ time for i in {1..1000}; do ./hello.py; done
anonymous
()

В груви тоже проблема была с указанием типов: когда они указывались, интерпретатор делал дополнительные проверки и исполнение кода замедлялось.

Deleted
()

Пиши самодокументируемый код.

anonymous
()
Ответ на: комментарий от Deleted

Так себе помогают, mypy довольно тупой, но это действительно лучше чем ничего. А вот IDE умнеет на глазах, во всю использую типизацию именно ради этого. Но вообще, я бы лучше этого не делал, ибо смысла никакого.

WitcherGeralt ★★
()
Ответ на: комментарий от Deleted

В питоне аннотации ни на что не влияют, издержки есть только при парсинге.

WitcherGeralt ★★
()

Аннотирование исходного кода отрицательно сказывается на времени запуска программ на Python?

Так-то конечно да, поскольку нужно как минимум импортировать typing, как максимум - импортировать всё то что раньше можно было протащить через свои классы и модули как «неизвестно что». Плюс какой-то оверхед на парсинг. Но на своём коде (10k sloc) я разницы не заметил. В рантайме оверхеда в любом случае никакого нет.

И вообще стоит ли писать весь код аннотируя везде? Вы как относитесь к аннотациям в Python?

Абсолютно стоит, так питон становится наконец похож на язык программирования. Упрощает рефакторинг и спасло уже от кучи проблем в рантайме. Если нет достаточного покрытия тестами, незаменимо, а просто полезно вообще всегда.

slovazap ★★★★★
()
Последнее исправление: slovazap (всего исправлений: 2)
Ответ на: комментарий от anonymous

Чтобы сбросить страничный кэш, dentry и inodes:

echo 3 > /proc/sys/vm/drop_caches
perl --version

This is perl 5, version 30, subversion 0 (v5.30.0) built for x86_64-linux-thread-multi
python -V
Python 3.7.3
pypy -V
Python 2.7.13 (8cdda8b8cdb8ff29d9e620cccd6c5edd2f2a23ec, Apr 23 2019, 17:07:51)
[PyPy 7.1.1 with GCC 8.3.0]

CPython

time python -c 'print("Hello World")'
Hello World

real    0m0.740s
user    0m0.028s
sys     0m0.008s

Второй запуск:

time python -c 'print("Hello World")'
Hello World

real    0m0.055s
user    0m0.012s
sys     0m0.013s

PyPy

time pypy -c 'print("Hello World")'
Hello World

real    0m0.754s
user    0m0.040s
sys     0m0.040s

Второй запуск:

time pypy -c 'print("Hello World")'
Hello World

real    0m0.120s
user    0m0.066s
sys     0m0.020s

Perl 5

time perl -e 'print "hello\n"'
hello

real    0m0.446s
user    0m0.000s
sys     0m0.010s

Второй запуск:

time perl -e 'print "hello\n"'
hello

real    0m0.004s
user    0m0.000s
sys     0m0.004s
menangen ★★★★★
()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от anonymous
time for i in {1..1000}; do luajit -e 'io.write("Hello World!\n")'; done

если ты хочешь позадротить с вводом выводом в bash pipe

menangen ★★★★★
()
Ответ на: комментарий от menangen

А питон стартует относительно медленно первый раз

А только первый раз обычно и нужен. Мне тут приходится на перле писать когда время запуска критично. Перл еще и заметно быстрее на строках и регулярках к тому же.

bread
()
Ответ на: комментарий от menangen

И что можно увидеть в твоих числах? Что одно и то же измерение покажет результат различающийся в 1000 раз? Что в резултате только одна значимая цифра, что следующая цифра сможет поменять результат на 25%? Статистические выбросы? Что в семье не без урода?

Я тебе показал как примерно составить эксперимент: отдельный исполняемый скрипт, который дергается (статистически) заничимое количество раз.

anonymous
()

А ещё длинные названия переменных замедляют, т.к. файл с диска надо читать, но это не повод писать говнокод и заниматься преждевременными оптимизациями на спичках. Вот когда программа работает и тормозит, тогда стоит задуматься почему и что с этим делать.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 2)
Ответ на: комментарий от peregrine

А ещё длинные названия переменных замедляют, т.к

Вот кстати да, поэтому Java так и тормозит!

Deleted
()
Ответ на: комментарий от menangen

А теперь оберни «hello world» в переменную из одной буквы и из 20. И проверь.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Да да, и не тормозит она)) Вот в ассемблере все коротко:

mov ax,5
Поэтому и выполняется быстро, стыдно не знать...

Deleted
()

Пообколются своей утиной типизацией, а потом в аннотации долбятся.

pon4ik ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.