Объединение Санкт-Петербурга и Ленинградской области


Яндекс цитирования
Ремонт сайтов

Пусть всегда будет так ужасно! 
      Hародная мудрость. 
        

Оптимизация и эффективность программ.
Нанотехнологии

Перебор (overhead)

Я так за много лет и не смог освоить правило, предлагающее всегда пользоваться уже написанными библиотеками. За редким исключением. Причём, чем аскетичнее библиотека, тем скорее она входит в исключения, а чем она более функциональна и богата, тем скорее я вообще её не воспользуюсь. Я много раз пытался, но так и не смог. Вижу в парадигме "используй готовое" обман. Зачастую сложно правильно подобрать библиотеки и функции к своей задаче, так чтобы не получалось смешных ситуаций. Более того, никто и не подбирает в большинстве случаев, смотрят обычно по понятности API. Зачастую пользователем библиотеки не тестируется эти библиотеки на оптимальность, красоту кода и т.д. В итоге, где-то в недрах программы кишат двупроходные разборы строк, делающие split /'\s+'/. Вообще, сложно написать хорошую библиотеку с хорошим API, это понятно. Но вот скажите мне, что такое требует midnight commander, чтобы нарисовать мне два малофункциональных синих окошка? А perl DBI ставили? А перловый LibXML? А теперь представьте, что сейчас вы читаете этот текст, а внутри вашей машины копошится куча библиотек, с тысячами связей, подсвязей, оработок и проверок, а ещё больше пылится за компанию.

Я стал потихоньку приходить к мнению, что если что-то плохо универсиализируется и может быть достаточно просто написано индивидуально - должно быть написано индивидуально. Вся это иерарзия стандартных и нестандартных библиотек - самообман и деструктив.

Универсальность и унификация

Стал склоняться к переносимому байткоду и стандартным интерфейсам. Поисковый движок efind.ru убедил меня, что даже FS на интерпритируемом языке не невесть какая ересь. Вполне приемлимо. Во всяком случае, сервер опроса, написаный на python, на стресс-тесте ложится позже чем опрашиваемый им апач, отдающий элементарную статику, но писаный на Си. Интерпритация байткода по сравнению с присущими операционным системам наследием библиотек, библиотечек, контролирующих демонов и сложных конфигов - вполне себе эффективна и оптимальна. Тоже самое с интерфейсами. Смущавший меня 9P смущать перестал. Более быстрые "прямые" сервисы сильно проигрывают на уровне реализаций разбора и всяких прочих навесок, а главное - зачастую неумением (или из-за глупости того кто пользует, или из-за непродуманности интерфейса) эту "прямоту" правильно использовать.

LoC (Less of Code)

Не знаю зачем люди пишут много кода. Деление кода на куски и выделение этих кусков в функции и объекты для удобства - это здорово. Но по-моему сейчас то достигло дьявольской феерии перебора. Я тут когда асинхронный неблокирующий опрос делал для "опрашивателя" смотрел много кода. Как люди ООП использую - жесть. Нет, код красивый, коментарии там всякие, методы нужные и выглядит даже гармонично. Приведу древний как мир пример - математические функции. Очень часто в формулах с рядами (а именно они используются для аппроксимации при вычислении сложных функций) требуется взять модуль числа. Ну, народ и пишет функцию abs() где происходит некое машинное "fabs @R0". И потом, соответственно, при расчётах её и вызывает. Красиво и идеологично. Однако, страшно неоптимально - и по коду, и по скорости будет верно использовать каждый раз "fabs @R0" против достаточно дорогостоящего вызова функции. Обработка ошибок - то отсутсвует, то внутри приватной части программы аргумент в каждой функции из очереди вызова проверяется на ОДЗ. А Вы помножте это время на 100000 вызовов этой функции... Вобщем, стал следить за кодом, просчитывать варианты....

© Phil Kulin, 07 Мая 2007 г.