Re: Что тяжелее - внешний процесс или вызов библиотеки?
2014-02-06 2:26 GMT+04:00 Artem Chuprina r...@ran.pp.ru: Прогресс, кстати, отдельный таракан. Понимание того, какую часть работы ты уже сделал - отдельная задача, в ряде случаев еще и теоретически неразрешимая. А в ряде других - разрешимая, но за слишком большую дополнительную цену. Вон, у того же rsync сколько ручек для оптимизации обработки набора файлов для синхронизации. Две трети из них приводят к не особой осмысленности информации о прогрессе. Ну, знаешь ты, что тебе еще треть файлов копировать. А по времени? Правильно, пока он все файлы не синхронизирует, он этого не знает. Теория вероятности не помогает, распределение изменений, как правило, неравномерно. А когда синхронизировал - ну, 100%. Ну, это если под прогрессом понимать исключительно %. (А почему, кстати, Артем сразу думает, что речь о процентах общего времени?) Бывает иногда полезно не %, а хотя-бы статус в виде 3 из 7. работаю. Всё
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Бывает иногда полезно не %, а хотя-бы статус в виде 3 из 7. работаю. Всё лучше чем тишина Сорри, нажал не ту кнопку.
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Damir Hakimov - debian-russian@lists.debian.org @ Fri, 7 Feb 2014 14:16:51 +0400: Бывает иногда полезно не %, а хотя-бы статус в виде 3 из 7. работаю. Всё DH лучше чем тишина DH Сорри, нажал не ту кнопку. А толку? Если ты ее запустил, то она работает. А продвигается или зациклилась на третьем из семи... Какая разница, зациклилась она на первом, третьем или седьмом? Интересна оценка, когда она закончит. А то у меня есть тут архив аж с тремя файлами. Два по нескольку десятков байт, а третий - пара гигабайт. Зазипованный образ виртуалки, ага. Ну, архиватор еще может выводить _два_ прогресса. 3 из 7, байт 98273948 из 297349827498273. Тут хотя бы понятно, что если третье из этих чисел давно не менялось, то он, вероятно, не работает... Но 7z t выводит вот ровно 3 из 7. В смысле, имена тех, которые уже обработал. P.S. В Индии на билетах на поезд не пишут время прибытия. Потому что кто ж знает, когда он прибудет? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87a9e3p5fz@wizzle.ran.pp.ru
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Oleksandr Gavenko gaven...@gmail.com writes: Формат вывода большинства утилит не стандартизирован, отсутствует документация и гарантии что новые версии не изменят формат вывода, тогда как для библиотечных вызовов зачастую есть документация и вызовы предварительно помечаются как устаревшие, обратно-несовместимые библиотеки изменяют пространство имен. С этой точки зрения библиотеки предпочтительней. Дельного ничего не посоветую, а просто повздыхаю. Это беда, на самом деле. Зачастую выпарсивание нужных данных выглядит как нереально страшный костыль. Правильно вот выше заметили. Причем костыль, который завтра может запросто поменяться и вообще сбить с толку прежний код. Вообще, утилиты в *NIX надо бы писать изначально так, чтобы ими было удобно пользоваться в скриптах: то есть не только human-readable вывод делать, но также и удобный текстовый вывод для скриптов. Лучше даже как-то однообразно и для всех утилит, чтобы можно было единым образом получать какие-то параметры, единообразно получать информацию о прогрессе (если таковая выдается). Но вот как-то не сложилось в нашем мире. Культура у разработчиков разная. Если мне придется в будущем делать какие-то утилиты, то я изначально буду проектировать так, чтобы можно было удобно скриптовать. Если по теме, то от утилиты зависит. Смотря какая утилита, смотря какая библиотека. Одни ломают каждый раз вывод, другие годами ничего трогают, а некоторые даже принципиально не меняют. Библиотека тоже смотря какая. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txcdmg6a@tochka.ru
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Evgeny M. Zubok - debian-russian@lists.debian.org @ Thu, 06 Feb 2014 00:57:01 +0400: EMZ Вообще, утилиты в *NIX надо бы писать изначально так, чтобы ими было EMZ удобно пользоваться в скриптах: то есть не только human-readable вывод EMZ делать, но также и удобный текстовый вывод для скриптов. Лучше даже EMZ как-то однообразно и для всех утилит, чтобы можно было единым образом EMZ получать какие-то параметры, единообразно получать информацию о EMZ прогрессе (если таковая выдается). Но вот как-то не сложилось в нашем EMZ мире. Культура у разработчиков разная. Если мне придется в будущем EMZ делать какие-то утилиты, то я изначально буду проектировать так, чтобы EMZ можно было удобно скриптовать. Вот как-то не удается народу придумать более-менее универсальный протокол машинночитаемого обмена данными. В основном не удается задать структуру. EMZ Если по теме, то от утилиты зависит. Смотря какая утилита, смотря какая EMZ библиотека. Одни ломают каждый раз вывод, другие годами ничего трогают, EMZ а некоторые даже принципиально не меняют. Библиотека тоже смотря какая. Все-таки утилита, выдающая человекомчитаемый формат, не только не обязана, но ей и не следует упорствовать в неменянии формата. Мне попадалось одна-две утилиты (rsync вот сходу вспоминается), у которых есть _отдельный_ машинночитаемый формат. И то он у них обычно далек от универсального, в смысле, страдает хреновой расширяемостью. Трудно добавить данные. Ну, для rsync это не так страшно, у него все же задача ограничена, там и нечего добавлять в отчет. Прогресс, кстати, отдельный таракан. Понимание того, какую часть работы ты уже сделал - отдельная задача, в ряде случаев еще и теоретически неразрешимая. А в ряде других - разрешимая, но за слишком большую дополнительную цену. Вон, у того же rsync сколько ручек для оптимизации обработки набора файлов для синхронизации. Две трети из них приводят к не особой осмысленности информации о прогрессе. Ну, знаешь ты, что тебе еще треть файлов копировать. А по времени? Правильно, пока он все файлы не синхронизирует, он этого не знает. Теория вероятности не помогает, распределение изменений, как правило, неравномерно. А когда синхронизировал - ну, 100%. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ob2lqjqo@wizzle.ran.pp.ru
Re: Что тяжелее - внешний процесс или вызов библиотеки?
On 2014-02-03, Dmitrii Kashin wrote: Впрочем, это рассуждение на пальцах. Если вопрос принципиально важен - замерьте, не поленитесь. Как мерить? strace -f - посчитать число системных вызовов? Или time? Или gettimeofday? Или http://en.wikipedia.org/wiki/Time_Stamp_Counter? Я работал с оптимизаций криптопримитивов - там использовали TSC, а как работать с более крупными исполняемыми кусками - не представляю... Мне кажется что микосекунд от gettimeofday достаточно для замеров. Как обычно - в цикле выполнить много раз и разницу во времени поделить на число итераций? -- Best regards! -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761ouzlgi@gavenkoa.example.com
Re: Что тяжелее - внешний процесс или вызов библиотеки?
On 2014-02-03, Dmitrii Kashin wrote: Заметно использование утилит для таких задач как нотификация: system(notify-send, Title, Msg); вместо сложностей с подключением libnotify. Часто встречаешь: cat file.txt | grep PATT pid=`cat serv.pid` вместо: grep PATT file.txt read pid serv.pid Ну так это всё от незнания и лени, скорее всего. Сегодня отлаживал почему APT::Periodic::Update-Package-Lists не работал. Все в /etc/cron.daily/apt Там на каждую настройку из /etc/apt/apt.conf вызывается на подобии: eval $(apt-config shell MaxAge APT::Archives::MaxAge) eval $(apt-config shell MaxAge APT::Periodic::MaxAge) eval $(apt-config shell MinAge APT::Archives::MinAge) eval $(apt-config shell MinAge APT::Periodic::MinAge) eval $(apt-config shell MaxSize APT::Archives::MaxSize) eval $(apt-config shell MaxSize APT::Periodic::MaxSize) eval $(apt-config shell Cache Dir::Cache::archives/d) eval $(apt-config shell CacheDir Dir::Cache/d) При этом каждый вызов сканит не только /etc/apt/apt.conf, но и /etc/apt/apt.conf.d/* Красвый shell-скрипт, но о том что бы просканировать конфигурационные файлы единожды - никто не беспокоится )) -- Best regards! -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871tzizl01@gavenkoa.example.com
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Oleksandr Gavenko - debian-russian@lists.debian.org @ Tue, 04 Feb 2014 22:12:13 +0200: Впрочем, это рассуждение на пальцах. Если вопрос принципиально важен - замерьте, не поленитесь. OG Как мерить? OG strace -f - посчитать число системных вызовов? OG Или time? OG Или gettimeofday? OG Или http://en.wikipedia.org/wiki/Time_Stamp_Counter? OG Я работал с оптимизаций криптопримитивов - там использовали TSC, а как OG работать с более крупными исполняемыми кусками - не представляю... OG Мне кажется что микосекунд от gettimeofday достаточно для замеров. OG Как обычно - в цикле выполнить много раз и разницу во времени поделить на OG число итераций? Для начала - подумать, что измеряем. Если ты работал с оптимизацией, то ты в курсе, что прежде чем оптимизировать, надо сделать профайлинг, и НЕ пытаться оптимизировать ничего, кроме того, что он показывает как узкое место. Сколько раз в секунду вызывается скрипт, про который идет речь? Если меньше 10, то оптимизировать надо время писателя или время читателя (в зависимости от того, одноразовый он или подразумевается его поддерживать), а не время выполнения. Соседнего твоего письма это в той же мере касается. Какая разница, один раз или двадцать оно сканирует десяток простеньких файлов по десять строк максимум в каждом, если после первого же сканирования все они осядут в кэше, а операция производится раз в сутки, и подобных операций в сутки десятка два максимум? Нет, конечно, даже там было что соптимизировать - там повторяющийся код. Но если подумать о том, что тут как раз надо оптимизировать время читателя, то получается, что этот код - оптимальный. Даже без чтения мана на apt-config практически сразу понятно, что он делает. Любая попытка что-то соптимизировать даже просто по объему кода (учитывая возможность copy-paste, даже время писателя уже особо не соптимизируешь) приводит к коду, который читается хуже. Можно было бы ради однопроходности обучить apt-config синтаксису вроде apt-config shell MaxAge=APT::Archives::MaxAge,APT::Periodic::MaxAge Cache=Dir::Cache::archives/d но тут уже читателю придется лезть в ман, чтобы понять, в каком порядке приоритета даны варианты, из какой настройки заполнять переменную - убывания или возрастания. В том коде понятно, это общее место императивного программирования - последний приоритетнее. Но вот положа руку на сердце - который из вариантов читается легче? Мне кажется, тот, где несколько проходов по конфигам. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvnysi45@wizzle.ran.pp.ru
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Oleksandr Gavenko gaven...@gmail.com writes: On 2014-02-03, Dmitrii Kashin wrote: Впрочем, это рассуждение на пальцах. Если вопрос принципиально важен - замерьте, не поленитесь. Как мерить? Когда я писал, я думал в основном про время. Но про strace замечание было очень дельное. Возможно, подсчёт системных вызовов даст более адекватную оценку. Мне кажется что микосекунд от gettimeofday достаточно для замеров. Как обычно - в цикле выполнить много раз и разницу во времени поделить на число итераций? Да. pgpPqynRI0Xcy.pgp Description: PGP signature
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Oleksandr Gavenko gaven...@gmail.com writes: При этом каждый вызов сканит не только /etc/apt/apt.conf, но и /etc/apt/apt.conf.d/* Красвый shell-скрипт, но о том что бы просканировать конфигурационные файлы единожды - никто не беспокоится )) У меня иногда складывается ощущение, что программы на баше - целиком и полностью кучка грязных хаков. Покажите мне на баше что-нибудь красивое, если не затруднит. Хочу нехорошие мысли прогнать. pgpQnzrl24ObW.pgp Description: PGP signature
Re: Что тяжелее - внешний процесс или вызов библиотеки?
Oleksandr Gavenko gaven...@gmail.com writes: Что тяжелее - внешний процесс или вызов библиотеки? Библиотека библиотеке рознь. Я не уверен, что в случае с GTK+ вызов библиотечной функции окажется быстрее, чем внешней программы. Xlib скорее всего оказался бы для данной задачи быстрее. Впрочем, это рассуждение на пальцах. Если вопрос принципиально важен - замерьте, не поленитесь. Если вопрос о правильной вещи, то я бы однозначно отдал предпочтение библиотеке, в которой есть функции специально для данных задач предназначенные. Утилиты меняются по желанию разработчика, а API библиотек есть тенденция поддерживать. Заметно использование утилит для таких задач как нотификация: system(notify-send, Title, Msg); вместо сложностей с подключением libnotify. Часто встречаешь: cat file.txt | grep PATT pid=`cat serv.pid` вместо: grep PATT file.txt read pid serv.pid Ну так это всё от незнания и лени, скорее всего. Т.е. сейчас тенденция создавать процессы - т.к. это понимает и знает каждый - значит быстрее, значит дешевле. Быстрее и дешевле *написать*. А как оно потребляет ресурсы, писавшему этот код, судя по всему, до лампочки. pgpeivyrQd_z1.pgp Description: PGP signature
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(rWidth: (\d+)).findall(output)[0] OG height = re.compile(rHeight: (\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 миллисекунд, которые тратятся раз в минуту или реже, оптимизировать бессмысленно. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fvnztk37@wizzle.ran.pp.ru
