Здравствуйте, dosik, Вы писали:
D>Здравствуйте, nigh, Вы писали:
N>>А что такое "высоконагруженые приложения", пример можно? Или вы чисто теоретически интересуетесь?
D>Да к примеру тот-же nginx — приложение, способное обрабатывает тысячи и дясятки тысяч запросов в секунду.
ну там код довольно понятно написан и излишних оптимизаций в виде слишком длинных функций или работы за оптимизатор в нем вроде нет (если не считать вещей вроде парсинга HTTP заголовков, но там оптимизация понятна и вынесена более-менее отдельно)
Здравствуйте, IT, Вы писали: IT>Считаю такое мнение признаком недопереквалифицированности.
я никогда не пишу код для себя. я всегда его пишу для других. лично мне было иногда бы удобнее все писать в столбик, просто я не хочу издеваться над девелоперами будущего, которые будут это править потом. залог понятного кода — его хорошая структурированность и понятные имена у элементов его структуры. чтобы понять что делает блок кода, не имеющий имени, уже нужно потратить свое время. заставлять людей тратить свое время на твоего кода невежливо
Здравствуйте, nigh, Вы писали:
N>ну там код довольно понятно написан и излишних оптимизаций в виде слишком длинных функций или работы за оптимизатор в нем вроде нет (если не считать вещей вроде парсинга HTTP заголовков, но там оптимизация понятна и вынесена более-менее отдельно)
Ну nginx изнутри не видел, сказать ни чего не могу. Я просто привел пример по Вашей просьбе.
Здравствуйте, __kot2, Вы писали:
__>я никогда не пишу код для себя. я всегда его пишу для других. лично мне было иногда бы удобнее все писать в столбик, просто я не хочу издеваться над девелоперами будущего, которые будут это править потом. залог понятного кода — его хорошая структурированность и понятные имена у элементов его структуры. чтобы понять что делает блок кода, не имеющий имени, уже нужно потратить свое время. заставлять людей тратить свое время на твоего кода невежливо
Почему ты думаешь, что другим разработчикам будет удобнее прыгать по куче маленьких функций при отладке или чтении кода? Меня, например, это напрягает. То, что советует Мартин (функции там у него по 2-5 строк) — это крайность. Такая же крайность, как и функции на сотни строк.
Понятный код — это совсем необязательно маленький размер функций. Функция в 50 строк может быть понятнее, чем функция в 10 строк. It depends, как обычно. Про передачу параметров, тут уже тоже упомянули.
И ты, на основании своего субъективного мнения, так мощно заявляешь, что программистов, пишущих функции длинее 30 строк надо не подпускать к коду? Имхо — это очень сильное, наглое и самоуверенное заявление.
Здравствуйте, MozgC, Вы писали: MC>Почему ты думаешь, что другим разработчикам будет удобнее прыгать по куче маленьких функций при отладке или чтении кода? Меня, например, это напрягает. То, что советует Мартин (функции там у него по 2-5 строк) — это крайность. Такая же крайность, как и функции на сотни строк.
меня тоже это поначалу раздражжало, когда для того, чтобы узнать по какому критерию вызывается сортировка, нужно перепрыгнуть к ф-ии, когда было бы удобно на месте ее указать. ну это еще до лямбд было. мне не нравилось, что много мелких ф-ий, которые так везде разбросаны-разбросаны и ты прыгаешь по ним. и называются еще как-нить типа sort1, sort2 или less.
но потом понял, что это скорее проблема бедности именования и хреновой структурированности, когда ты не можешь понять, что делает ф-ия по ее названию и тебе надо обязательно лезть внутрь посмотреть и когда вместо композиции из простых и понятных вещей, типа loader или там parser, единственное, на что тебя хватает это на имена в стиле process_part1(), part2() или do_extra_init()
MC>Понятный код — это совсем необязательно маленький размер функций. Функция в 50 строк может быть понятнее, чем функция в 10 строк. It depends, как обычно. Про передачу параметров, тут уже тоже упомянули.
у меня нет никаикх проблем разобраться в коде, только если это не буст. просто это занимает мое время. если я открываю код, а там спагетти без тестов ( а спагетти очень сложно тестировать — откуда там тестам взяться), то ценность этого кода практически отрицательная. его саппорт слишком дорог для реального использования.
MC>И ты, на основании своего субъективного мнения, так мощно заявляешь, что программистов, пишущих функции длинее 30 строк надо не подпускать к коду? Имхо — это очень сильное, наглое и самоуверенное заявление.
не думаю, что вы найдете хоть одну рекоменацию от авторитетного человека, который скажет обратное.
от опытного — да, конечно. я много людей знаю опытных, которые застряли где-то в начале 2000ых в своем подходе к написанию софта. в основном они заняты каким-то саппортом того, что кроме них уже саппортить никто не может. этот проект не будут развивать, его просто закроют на самом деле со временем. когда у нас в одной конторе такой человек ушел на пенсию и передал свои дела и обязанности, то вдруг выяснилось, что все, что он делал можно просто удалить и на самом деле никакого саппорта не нужно, и все уже было замещено новыми сервисами. примерно как с историей поддержки bcd чисел в процессорах.
__>любой человек, который до сих пор пишет ф-ии в столбик строк по 30, вставляя туда комменты просто неквалифицирован и его нельзя допускать до написания реального кода
Может и так. А еще мне кажется человек который так категоричен скорее всего тоже идет туда же.
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, IT, Вы писали: IT>>Считаю такое мнение признаком недопереквалифицированности. __>я никогда не пишу код для себя. я всегда его пишу для других. лично мне было иногда бы удобнее все писать в столбик, просто я не хочу издеваться над девелоперами будущего, которые будут это править потом. залог понятного кода — его хорошая структурированность и понятные имена у элементов его структуры. чтобы понять что делает блок кода, не имеющий имени, уже нужно потратить свое время. заставлять людей тратить свое время на твоего кода невежливо
"чтобы понять что делает блок кода, не имеющий имени" — не любите лямбды?
Здравствуйте, dosik, Вы писали:
D>Отвечу сам себе, поскольку основная масса ответов идентична — не бери на себя работу компилятора, пиши удобочитаемый код, а компилятор сам все заинлайнит. D>А что тогда с высоконагруженными приложениями, где кроме как на себя, даже на компилятор положиться нельзя?
1) Какова доля высоконагруженного кода в высоконагруженном приложении? По моему опыту, очень невелика. Этот код можно писать несколько в другом стиле.
2) Вы точно уверены, что ваше высоконагруженное приложение упирается именно в процессор, а не в сеть, диск и т.п.?
3) Выбор подходящих алгоритмов и структур данных дает, как правило, больший выигрыш, чем низкоуровневая оптимизация
Здравствуйте, dosik, Вы писали:
N>>А что такое "высоконагруженые приложения", пример можно? Или вы чисто теоретически интересуетесь?
D>Да к примеру тот-же nginx — приложение, способное обрабатывает тысячи и дясятки тысяч запросов в секунду.
Говорят, что HTTP-сервер, входящий в стандартную библиотеку языка Go, проигрывает nginx'у на раздаче статического контента всего в два раза. При том, что в отличии от nginx'а, он написан на высокоуровневом языке со сборкой мусора, и никто особо не напрягался оптимизировать его по скорости. И кроме того, у компилятора Go простой и наивный оптимизатор, в отличии от gcc, которым обычно компилируют nginx.
Здравствуйте, Философ, Вы писали:
Ф>О такой мелочёвке нужно можно заботиться только после того как ты отпрофилировал программу. До профайлинга нужно написать удобочитаемый и легко изменяемый код. Ф>Когда после профилировки ты выяснишь, что у тебя какой-нибудь Math.Max() не заинлайнен компилятором, и существует милиард его вызовов, и что от милиарда вызовов никуда не уйти (а именно в этом бОльшая часть оптимизаций и заключается), тогда и заинлайнишь — не раньше. Ф>В ином случае ты рискуешь во время написания отловить блох, а в итоге получить O(n!) там, где должен быть O(n log(n)).
Заметим, чтобы получился O(n log(n)), об этом надо сразу думать, еще на стадии проектирования.
Т.е., идея, что сначала пишем красиво, потом когда-нибудь оптимизируем, работает в отношении низкоуровневых оптимизаций. Но если вы выбрали на стадии проектирования такое представление данных, что быстрее, чем за время O(n^3) с ними работать не получается, вряд ли вы на поздней стадии получите хотя бы O(n^2)
Здравствуйте, dosik, Вы писали:
D>В своей книге Р. Мартин утверждает, что функции необходимо предъявлять всего два требования: D>1. они должны быть компактными D>2. они должны быть еще более компактными D>Т.е. функция должна выполнять лишь одну операцию. Функции, выполняющие несколько операций необходимо дробить на несколько. D>Тогда вопрос: А как же накладные расходы на вызов функции? Ведь вместо того, чтобы продолжить вычисления, теперь нам надо заполнить стек и передать управление по адресу, а по возвращению очистить стек. Т.е. улучшая читабельность кода мы уменьшаем производительность системы. Да и как то меня учили, что в функцию необходимо выносить лишь тот код, который может быть вызван из нескольких участков программы. И какой тогда смысл выносить в отдельную функцию код, который будет вызываться только в одном месте?
В свое время, помню развертывали циклы, при обработке векторов "руками", пока инженер из интел-а не сказал что это мешает оптимизатору применить sse инструкции.
В моей практике был один случай, когда разбиение функции из 5 строчек на две привело к повышению производительности.
"Вкусы" компиляторов (и процессоров) сейчас так быстро меняются, что разумнее всего тратить время на оптимизацию алгоритма, а не кода.
Если потратить время на оптимизацию кода, через n-лет все-равно придется этот кусок переписать.
Поэтому занимаясь оптимизацией главное сохранять код понятным.
Здравствуйте, Chorkov, Вы писали:
C>"Вкусы" компиляторов (и процессоров) сейчас так быстро меняются, что разумнее всего тратить время на оптимизацию алгоритма, а не кода. C>Если потратить время на оптимизацию кода, через n-лет все-равно придется этот кусок переписать. C>Поэтому занимаясь оптимизацией главное сохранять код понятным.
Вот тут наверное полностью соглашусь: не все, что хорошо соптимизирует компилятор от Intel, так же хорошо соптимизирует компилятор MS. Аналогично с Clang и GCC. И аналогично для одного и то-же компилятора сегодня и завтра ))) Так что при написании кроссплатформенных вещей возможно следует расставить приоритеты как Вы и указали — оптимизируем код не в ущерб читаемости. Здесь видимо и есть та грань балансировки, которую сам для себя должен найти каждый.
Здравствуйте, gardener, Вы писали: __>>любой человек, который до сих пор пишет ф-ии в столбик строк по 30, вставляя туда комменты просто неквалифицирован и его нельзя допускать до написания реального кода G>Может и так. А еще мне кажется человек который так категоричен скорее всего тоже идет туда же.
мы в школе как-то запланировали идти в трехдневный поход. мы народ был уже опытный, брали только самое необходимое, так, пару кг личных вещей и еду заранее всю приготовили, легкие крупу и сухари в основном, поделили между самыми сильными-выносливыми. даже с учетом того, что я нес кучу еды, рюкзак весил всего по-моему 14 кг — смешно просто. поход обещал был легким и приятным. приехали мы на начало маршрута, я выбегаю из автобуса налегке, готовый сейчас прямо за пару часов взбежать на соседнюю гору и тут замечаю девочку, которая выйдя из автобуса стоит держится за лямку огромного рюкзачища, лежаего на земле. она его даже волоком сдвинуть не может. понятно, "мальчики, помогите девочкам, возьмите у кого рюкзаки тяжелые". я отдаю ей свой рюкзак, пытаюсь поднять ее баул и просто вращаюсь вокруг него на одной ноге — он килограмм 60. полный рюкзак картошки и консерв!
делать нечего, нас трое таких счастливцев оказалось и мы поперлись, сильно отставая от группы, небольшими перебежками, согнувшись втрое. пришли вечером на несколько часов позже остальных, жутко матерясь. на утро конечно, выкинули просто эти полтонны картошки, что не сьели и пошли дальше уже по нормальному.
так и прогрммист со своими функциями-спагетями это нечто среднее между маленькой девочкой с мешком картошки и фашистом с гранатой, в зависимости от его должности и степени влияния на проект. он все равно не сможет контролировать сложность проекта сам или же вообще самоустранится и предложит другим разбираться с проблемами.
бывает, что есть производственная необходимость работать с таким кодом и тогда начинается, как Cyberax выражается, санация кода — когда говнокодер отстраняется от проекта, а из проекта все выкидывается по максимуму, упрощается и пишутся нормальные тесты. но это совсем не обязательный этап жизни ПО, надо просто брать с собой в горы проверенных людей, которые понимают, что и как делать надо, а не просто что-то делают, а потом как получится.
Здравствуйте, Transformerrr, Вы писали: T>"чтобы понять что делает блок кода, не имеющий имени" — не любите лямбды?
почему, для вещей вроде for_each отлично подходят
D>Вот тут наверное полностью соглашусь: не все, что хорошо соптимизирует компилятор от Intel, так же хорошо соптимизирует компилятор MS. Аналогично с Clang и GCC.
Самая жуть, когда один компилятор вообще не оптимизирует конструкцию, которая единственная даёт верный код на другом компиляторе.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
D>Тогда вопрос: А как же накладные расходы на вызов функции?
Мизерны
D>Ведь вместо того, чтобы продолжить вычисления, теперь нам надо заполнить стек и передать управление по адресу, а по возвращению очистить стек.
Зависит от языка и компилятора/интерпретатора. В языках с tail recursion в случае, если последнее возвращаемое значение из функции — это вызов другой функции, стек не будет заполняться и потом очищаться.
D>Т.е. улучшая читабельность кода мы уменьшаем производительность системы.
На сколько? На 0.00001%?
D>Да и как то меня учили, что в функцию необходимо выносить лишь тот код, который может быть вызван из нескольких участков программы.
Плохо тебя учили. Выносить в функцию надо логические единицы. Иначе подавляющее большинство программ уместится в от силы десяток функций длинной по 50 000 строчек.
Здравствуйте, dosik, Вы писали:
D>В своей книге Р. Мартин утверждает, что функции необходимо предъявлять всего два требования: D>1. они должны быть компактными D>2. они должны быть еще более компактными D>Т.е. функция должна выполнять лишь одну операцию. Функции, выполняющие несколько операций необходимо дробить на несколько. D>Тогда вопрос: А как же накладные расходы на вызов функции?
Примерно так — если компилер плохой, то ты ему помогаешь. Если хороший, то он помогает тебе.
Но вообще,
0 вкуриваешь проблему, пока всё не станет ясно
1 пишешь, как тебе понятно именно сейчас
2 рефакторишь, когда перестаёшь понимать
3 замеряешь-профилируешь,
а после того, как готов функционал
б когда есть на то основания (нагрузка, тестеры, юзеры, сведения из других источников)
в учитывать надо и абсолютные и относительные величины
г учитывать фазовые переходы вида 'лед превращается в пар минуя воду'
4 оптимизируешь только самое узкое место, его покажут замеры-профилирование
5 тестируешь нагрузкой, когда в требованиях явно или неявно указана эта нагрузка
Когда все 6 пунктов в наличии, и у тебя есть свободное время, можешь подумать про компактность, кошерность, правильность, хорошесть и прочие православности.
PS Когда найдешь того, кто, например, сначала оптимизирует или даже добивается православности, и только потом решает проблему, действуй в соответствии с должностными отношениями.
Здравствуйте, К Тёте, Вы писали:
D>>Т.е. улучшая читабельность кода мы уменьшаем производительность системы.
КТ>На сколько? На 0.00001%?
Иногда и 1000%. Вопрос скорее в частоте встречаемости в разных областях. Если компилятор не делает инлайн, что часто бывает с разными лямбдами, интерфейсами и прочими интересными вещами, то надо помнить, что вызовы таких функций дороже чем, скажем, инкремент.
Соответственно вопрос только в количестве вызовов.
В числодробилках, рендеринге, разных системных тонкостях даже дополнительный инкремент может опаскудить вообще всё. Лямбда, которая содержит такой инкремент, добавит цимеса настолько, что мир покажется холодным и скучным, а Валгалла и Фольквангр отвернутся от тебя.
