[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Что тяжелее - внешний процесс или вызов библиотеки?



Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Mon, 03 Feb 2014 22:29:53 +0200:

 OG> Допустим понадобилось узнать разрешение экрана. Что лучше:

 OG>   import gtk.gdk
 OG>   print("%dx%d" % (gtk.gdk.screen_width(), gtk.gdk.screen_height()))

 OG> или:

 OG>   from commands import getstatusoutput
 OG>   status, output = getstatusoutput("xwininfo -root")
 OG>   width = re.compile(r"Width: (\d+)").findall(output)[0]
 OG>   height = re.compile(r"Height: (\d+)").findall(output)[0]
 OG>   print("%sx%s" % (width, height))

 OG> ================================================================

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

 OG> С этой точки зрения библиотеки предпочтительней.

 OG> ================================================================

Тут ты скорее прав.  Есть еще, правда, момент совместимости с чужой
системой.  Если тебе библиотека /все равно/ нужна для работы, то лучше
библиотека.  Если для работы она тебе не нужна, то ее на месте может не
быть (если ты делаешь отчуждаемую программу).  В этом смысле может
оказаться умнее использовать утилиту, если ты можешь пережить без ее
результатов, и/или если есть несколько альтернативных утилит.

Скажем, если ты имеешь в виду скриптовую программу, которую ты будешь
выполнять на клиентских виндах, то можно рассчитывать на библиотеки,
которые /сразу/ идут в комплекте какого-нибудь ActivePython, а те, для
установки которых нужны какие-то телодвижения, даже запуск штатного
питоновского package manager'а, или кто у него там (я конкретно с
ActivePython не работал, но общался с ActivePerl), лучше не
использовать.  Потому что "запустите инсталлятор по умолчанию" - это
адекватное телодвижение для энд-юзера, а "после инсталляции запустите
cmd, пойдите туда, и скажите еще пять команд" - нет, энд-юзер этого
пугается.

И кстати, с обратной совместимостью тоже интересно.  Что-то мне
подсказывает, что формат вывода конкретно xwininfo меняется реже, чем
API gtk :) Хотя /настолько/ базовый API вряд ли меняется чаще.  Чаще
может меняться команда для импорта, кстати.  Зато с кроссплатформенной
совместимостью у gtk куда лучше, на виндах xwininfo, сюрприз,
гарантированно отсутствует.  Но если тебе все равно gtk нужна для
работы, то лучше пользоваться библиотекой.

 OG> Заметно использование утилит для таких задач как нотификация:

 OG>   system("notify-send", "Title", "Msg");

 OG> вместо сложностей с подключением libnotify.

 OG> Часто встречаешь:

 OG>   cat file.txt | grep PATT
 OG>   pid=`cat serv.pid`

 OG> вместо:

 OG>   grep PATT <file.txt
 OG>   read pid <serv.pid

Это просто от плохого знания шелла.  Я, кстати, сам пиды читаю по
первому варианту, а не по второму :)

 OG> Т.е. сейчас тенденция создавать процессы - т.к. это понимает и знает каждый -
 OG> значит быстрее, значит дешевле.

 OG> ================================================================

 OG> Вот мне и не понятно как правильно...

А это сильно зависит от того, что ты имеешь в виду на предмет 1) времени
на получение результата и 2) дальнейшей жизни скрипта.  Если ты пишешь
скрипт сугубо для себя, то обычно выгоднее иметь его максимально
компактным и ясно читаемым, и тут system("notify-send"), вероятно,
выиграет у подключения библиотеки.  А парсинг вывода xwininfo, вероятно,
проиграет.  За счет парсинга, ага.  А если ты делаешь отчуждаемый код,
то надо думать о том, что будет, если система, где он будет выполняться,
отличается от твоей.  И чем она будет отличаться.

А сколько времени оно работает - 10 миллисекунд, которые тратятся раз в
минуту или реже, оптимизировать бессмысленно.


Reply to: