Иногда меня обвиняют в овердизайне. На вскидку вспоминается два случая. Один из которых — заслуженный (но через этот опыт надо было пройти), а со вторым обвинением я не согласен. Обвинение это было выдано говно-программистом, тем самым Васей, который наклепал тяп-ляп проект, начал стричь бабло и набрал людей, чтобы они переписали ага, как же, переписали... Щас. Чтобы они продолжали гнать функционал поверх рассыпающегося говна, но это другая история.
А нынешняя история следующая: я тут пилю вещи, превышающие мою квалификацию (логика сложноразмазана между compiletime (макросы) для статически оптимизируемых случаев и runtime (генерируемый макросами код) для динамических неоптимизируемых, а dragon book так и не дочитал, поэтому всё на костылях). И обнаруживаю, что пишу как раз в стиле того говно-программиста — без паттернов, которых не знаю, без нормальной структуры — грубая копипаста в стиле "как слышится, так и пишется".
Вывод: говнокод начинается, когда пытаешься проглотить слишком большой кусок ненатренированной глоткой.
А ещё вспоминается метода Кента Бека (описана кажется в TDD): 10 пишем лишь бы работало; 20 удаляем задвоения кода; goto 10. Только вот в данном случае на входе шага 20 будет строк эдак 5-10 тысяч, зубодробительных костылей. Как там я буду задвоения искать и удалять/заворачивать в паттерны — одному богу известно.
D>А ещё вспоминается метода Кента Бека (описана кажется в TDD): 10 пишем лишь бы работало; 20 удаляем задвоения кода; goto 10. Только вот в данном случае на входе шага 20 будет строк эдак 5-10 тысяч, зубодробительных костылей. Как там я буду задвоения искать и удалять/заворачивать в паттерны — одному богу известно.
немного офф: не так уж редко встречаются ситуации, когда удаление повторений делает код хуже (потому что вводится лишняя сущность, и если она недостаточно generic, то она просто добавляет шум).
Здравствуйте, dimgel, Вы писали:
D>Иногда меня обвиняют в овердизайне.
а может правильно обвиняют? часто пытаясь спи... нет, даже не скопипастить, а просто выдрать часть кода из чужого проекта и скомпилировать в независимую утилиту, натыкаюсь на этот самый овер-дизайн. это когда на ровном месте создаются средства устранения проблем, порожденных самими средствми их устранения. скажем, проект имеет библиотеку разных алгосов поиска. и все бы хорошо, но там у них свои типы на все случаи жизни, своя динамическая память, которая в свою очередь опирается на свои же очереди и свои же алгоритмы... поиска и сортировки.
это даже хуже, чем говнокод. потому что никакой его фрагмент не работает без кода всего проекта. следовательно, повторное использование кода возможно только на уровне АПИ высшего уровня. а где-то там внутри есть такой клевый компилятор регулярных выражений в nfa, вот только его проще переписать заново чем тянуть за собой в другой проект кучу мусора.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
D>>Иногда меня обвиняют в овердизайне. М>а может правильно обвиняют?
Ну тебе виднее, разумеется.
М>а где-то там внутри есть такой клевый компилятор регулярных выражений в nfa, вот только его проще переписать заново чем тянуть за собой в другой проект кучу мусора.
Овердизайн выглядит несколько по-другому, а описанная тобой проблема — слишком сильная связность — это как раз следствие отсутствия дизайна как такового.
Здравствуйте, dimgel, Вы писали:
D>А нынешняя история следующая: я тут пилю вещи, превышающие мою квалификацию (логика сложноразмазана между compiletime (макросы) для статически оптимизируемых случаев и runtime (генерируемый макросами код) для динамических неоптимизируемых, а dragon book так и не дочитал, поэтому всё на костылях). И обнаруживаю, что пишу как раз в стиле того говно-программиста — без паттернов, которых не знаю, без нормальной структуры — грубая копипаста в стиле "как слышится, так и пишется".
D>Вывод: говнокод начинается, когда пытаешься проглотить слишком большой кусок ненатренированной глоткой.
Это вы очень хорошо написали. Вещи очевидные, но интересно, что в явном виде обычно об этом не пишут. Я бы даже немного обобщил: у любого программиста есть какое-то количество ресурсов, которые ему при "занятиях работой" нужно раскидать по примерно такому списку направлений:
1. Понимание задачи (чтение, коммуникации, анализ, "постановка для себя", риски, гуглинг)
2. Выдумывание решения (понимание "достаточно хорошего решения", риски, самокритика, эксперименты, поиск готовых решений, гуглинг, релевантный опыт)
3. Решение задачи (написание кода, самокритика, рефакторинг, тестирование, релевантный опыт)
Всякие джуниоры-сеньоры отличаются как раз по общему количеству доступного им ресурса и по желанию/возможности/способности разделить этот ресурс между вышеописанными пунктами. В качестве примера возьмём задачку, которая требует 5/5/10.
Если мы джуниор с общим ресурсом 7, то раскидаем ресурс например вот так:
1. Понимание — 1/5 (прочитали тикет)
2. Выдумывание решения — 1/5 (прикинули в уме)
3. Решение — 5/10 (написали какой-то код)
Если мы сеньор с общим ресурсом 100, то "ожидается", что мы сможем обеспечить все эти самые 5/5/10 с хорошим запасом (скучная задачка).
Но вот если задачка требует ресурс 200, то сеньор с общим ресурсом 100 такую задачку уже не потянет.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, мыщъх, Вы писали:
D>>>Иногда меня обвиняют в овердизайне. М>>а может правильно обвиняют? D>Ну тебе виднее, разумеется.
я же спрашиваю, а не утверждаю. динамическим программированием я и сам увлекаюсь. а книга дракона это далеко не самое лучшее чтиво. я бы Modern Compiler Implementation in C рекомендовал.
М>>а где-то там внутри есть такой клевый компилятор регулярных выражений в nfa, вот только его проще переписать заново чем тянуть за собой в другой проект кучу мусора. D>Овердизайн выглядит несколько по-другому, а описанная тобой проблема — слишком сильная связность — это как раз следствие отсутствия дизайна как такового.
это как раз пример налучшего дизайна. вот только лучший враг хорошего. библиотека динамической памяти использует же списки, очереди, поиск и прочие структуры данных и алгоритмы? а библиотека поиска динамическую память использует? использует!
что плохого в том, что модуль А использует модуль Б, а модуль Б использует модуль А? это как раз красиво, структурно и архитектурно. а вот кк тащить в свой проект эту красоту -- это да.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>скажем, проект имеет библиотеку разных алгосов поиска. и все бы хорошо, но там у них свои типы на все случаи жизни, своя динамическая память, которая в свою очередь опирается на свои же очереди и свои же алгоритмы... поиска и сортировки. М>это даже хуже, чем говнокод. потому что никакой его фрагмент не работает без кода всего проекта. следовательно, повторное использование кода возможно только на уровне АПИ высшего уровня. а где-то там внутри есть такой клевый компилятор регулярных выражений в nfa, вот только его проще переписать заново чем тянуть за собой в другой проект кучу мусора.
это не овердизайн, а недостаток дизайна.
при нормальном дизайне все части были бы завернуты в абстрактные интерфейсы, и любая часть легко заменялась бы (в тех же тестах)
Здравствуйте, Abyx, Вы писали:
A>при нормальном дизайне все части были бы завернуты в абстрактные интерфейсы, и любая часть легко заменялась бы (в тех же тестах)
Легко заменялась, написав десяток классов-оберток. И дико бы тормозило.
Здравствуйте, kleng, Вы писали:
K>Здравствуйте, Abyx, Вы писали:
A>>при нормальном дизайне все части были бы завернуты в абстрактные интерфейсы, и любая часть легко заменялась бы (в тех же тестах)
K>Легко заменялась, написав десяток классов-оберток. И дико бы тормозило.
да, я всегда замечал что как только применю статический полиморфизм — всё сразу начинает тормозить
Здравствуйте, dimgel, Вы писали:
D>Иногда меня обвиняют в овердизайне. На вскидку вспоминается два случая. Один из которых — заслуженный (но через этот опыт надо было пройти), а со вторым обвинением я не согласен. Обвинение это было выдано говно-программистом, тем самым Васей, который наклепал тяп-ляп проект, начал стричь бабло и набрал людей, чтобы они переписали ага, как же, переписали... Щас. Чтобы они продолжали гнать функционал поверх рассыпающегося говна, но это другая история.
D>А нынешняя история следующая: я тут пилю вещи, превышающие мою квалификацию (логика сложноразмазана между compiletime (макросы) для статически оптимизируемых случаев и runtime (генерируемый макросами код) для динамических неоптимизируемых, а dragon book так и не дочитал, поэтому всё на костылях). И обнаруживаю, что пишу как раз в стиле того говно-программиста — без паттернов, которых не знаю, без нормальной структуры — грубая копипаста в стиле "как слышится, так и пишется".
D>Вывод: говнокод начинается, когда пытаешься проглотить слишком большой кусок ненатренированной глоткой.
Неверно. Говнокод может быть в случаях когда квалификация программиста превышает требования задачи.
Скорее у тебя проблема с адекватной декомпозицией задачи. Кстати неверная декомпозиция — частая (возможно основная) причина говнокода.
D>А ещё вспоминается метода Кента Бека (описана кажется в TDD): 10 пишем лишь бы работало; 20 удаляем задвоения кода; goto 10. Только вот в данном случае на входе шага 20 будет строк эдак 5-10 тысяч, зубодробительных костылей. Как там я буду задвоения искать и удалять/заворачивать в паттерны — одному богу известно.
Бек пишет про отдельные фукнции, а не огромную систему. См выше про декомпозицию.
ЗЫ. Когда пытался писать нечто вроде компилятора, то сам столкнулся с ситуацией когда я не мог понять как надо декомпозировать задачу, чтобы успешно её решить.
Здравствуйте, gandjustas, Вы писали:
G>ЗЫ. Когда пытался писать нечто вроде компилятора, то сам столкнулся с ситуацией когда я не мог понять как надо декомпозировать задачу, чтобы успешно её решить.
Похоже на то, если к проблемам декомпозиции относится смутное понимание, что здесь надо бы таблицу символов забабахать и собственное AST, но AST параллельное уже имеющемуся скаловскому — категорически лень, а как с этой самой таблицей символов работать, а главное, про технику оптимизаций — я полное ХЗ.
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, мыщъх, Вы писали:
A>это не овердизайн, а недостаток дизайна. A>при нормальном дизайне все части были бы завернуты в абстрактные интерфейсы, и любая часть легко заменялась бы (в тех же тестах)
к сожалению, этот "недостаток дизайна" на каждом шагу. как раз все части и завернуты в абстрактные интерфейсы. в результате чего библиотека поиска подстроки в строке работает с абстрактными строками. если бы строки были _действительно_ абстрактными (абстрактный "символ" вместо конкретного байта, где один и тот же символ может быть закодирован и одним, и двумя, и тремя, и четырьмя байтами, но функция сравнения символов это берет на себя). так ведь нет! слой абстракции от бинарного представления строки на самом деле является функциями-пустышками, тупо считывающими один или два байта и так же тупо их сравнивающих побитовым сравнением. и это как бы понятно, потому что быстро сравнить два символа в общем случае невозможно и придется либо держать в памяти огромные таблицы всех кодировок, либо требовать нормализации данных перед сранением). вот и возникает вопрос: зачем во многих проектах (CalmAV, SpiderMonkey) городить лишние сущности, если они не дают никакого профита?
еще одно наблюдения. в не-говнокоде как правило в одном файле реализована одна функция. профит? существенно меньший оверхид при линковке. если у нас есть своя библиотека и в ней 300 апи функций, но модуль foo использует только 10 из них, то линкеру, очевидно, требуется помощь. чтобы включать в проект только то, что реально используется.
а вот в говнокоде все это компилируется только одним большим куском говна. с другой стороны, до появления ссд дисков подход "один файл — одна функция" существенно замедлял компиляцию, по крайней мере нтфс очень плохо справляется с каталогами с кучей файлов
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>а просто выдрать часть кода из чужого проекта и скомпилировать в независимую утилиту, натыкаюсь на этот самый овер-дизайн
Да, даже ещё проще. Вот недавно надо было тривиальное изменение сделать в каком-то коде. Одна строчка кода. Ну и думаю, сейчас я быстренько юнит-тест для него накатаю. Делов-то: создать один объект и позвать у него один метод. Но не тут-то было! Это объект просто так не создашь. Для него надо фабрику, которую фиг знает где взять, а для фабрики нужны ещё и параметры, которые тоже объекты и которые тоже надо как-то сделать (через другие фабрики, duh!). И в довесок еще и аттрибуты для этих объектов правильно инициализировать. И это даже не джава. Клинический случай. Надо всё нафиг выбрасывать и заново делать.
Здравствуйте, мыщъх, Вы писали:
М>еще одно наблюдения. в не-говнокоде как правило в одном файле реализована одна функция. профит? существенно меньший оверхид при линковке.
Разработчики SQLite — говнок темные люди и не слышали о таких вещах, поэтому распространяют исходный код в виде одного большого файла. Который (вероятно из-за их неграмотности), компилируется на порядок быстрее, чем тот же код, разбитый на множество файлов.
Здравствуйте, kleng, Вы писали:
K>Здравствуйте, мыщъх, Вы писали:
М>>еще одно наблюдения. в не-говнокоде как правило в одном файле реализована одна функция. профит? существенно меньший оверхид при линковке.
K>Разработчики SQLite — говнок темные люди и не слышали о таких вещах, поэтому распространяют исходный код в виде одного большого файла. Который (вероятно из-за их неграмотности), компилируется на порядок быстрее, чем тот же код, разбитый на множество файлов.
см. выделенное. а на счет того, что один большой файл компилируется быстрее чем один маленький -- просите, не верю. вы в курсе, что make не перекомпилирует файлы, в которых нет изменений? если у нас много файлов, то правка одного из них не затронет остальные (если только нет зависимостей), значит, исправить-и-пересобрать в случае большого файла сильно медленнее.
вообще-то, мне нравится сорцы, состоящий из кирпичиков и каждый кирпичик это свой каталог со своим make. экономит время.
кстати, распростанять можно в чем угодно. я знал неглупых людей, распростаняющих исходники своего высокотехнологичного проета на си, но... в виде сетей петри. собрать-то можно под любой платформой, но ни понять как оно работает, ни изменить -- невозможно.
кстати, девелоперски репы очень часто _сильно_ отличаются от сорцов для хомячков, которым достаточно их собрать.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>еще одно наблюдения. в не-говнокоде как правило в одном файле реализована одна функция. профит? существенно меньший оверхид при линковке. если у нас есть своя библиотека и в ней 300 апи функций, но модуль foo использует только 10 из них, то линкеру, очевидно, требуется помощь. чтобы включать в проект только то, что реально используется.
Интересно, а есть примеры проектов с такой организацией?
По-моему опыту, удобней случаи с функциями, организованными в файлах по общей тематике. Например, математические функции в одном файле, работа со строками — в другом, скажем, поиск и работа с контурами — в третьем.
В чём удобство такой организации?
Во-первых, можно быстро, без документации узнать что есть в библиотеке, найти функцию, о которой даже и не думал. Например, вряд ли кто-то будет искать функцию clamp, sign или lerp — проще написать самому, порождая лишний мусор в исходниках. А так: заглянул, увидел, применил.
Во-вторых, меньше инклудов писать руками. С кучей файлов рано или поздно заколебаешься писать инклуд на каждую функцию и сделаешь самописную свалку инклудов, которая убьёт все преимущества такой мелкомодульности (хорошо ещё если в виде прекомпилированного заголовка).
И, в-третьих, уже лично для меня: не надо запоминать кучу сущностей. Помнить про один файл легче, чем про 10 или 20.
Здравствуйте, мыщъх, Вы писали:
М>см. выделенное. а на счет того, что один большой файл компилируется быстрее чем один маленький -- просите, не верю.
С вопросами веры — в церковь, а у нормальных людей принято делать эксперименты.
М>вы в курсе, что make не перекомпилирует файлы, в которых нет изменений?
В курсе. Но каждый добавочный файл — это нехилые накладные расходы, даже если он не компилируется, а только линкуется.
Здравствуйте, мыщъх, Вы писали: М>я же спрашиваю, а не утверждаю. динамическим программированием я и сам увлекаюсь. а книга дракона это далеко не самое лучшее чтиво. я бы Modern Compiler Implementation in C рекомендовал.
Да, Аппель — рулит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, мыщъх, Вы писали:
N>Интересно, а есть примеры проектов с такой организацией?
да много их. crt любого компилятора (той же студии), хром, лис...
N> По-моему опыту, удобней случаи с функциями, организованными в файлах по общей тематике. N> Например, математические функции в одном файле, работа со строками — в другом,
а в чем удобсто такого подходе? классика жанра при работе со строками -- сначала реализовали простые и тупые функции. страшно тормозные. потом заюзали продвинутые алгоритмы. потом еще более продвинутые. при этом начали постепенно отказываться от тупых функций. если функции были в разных файлах, то мертвый код не компилируется и не попадает в целевой файл. если же все функции в одном файле, нам придется вычищать их руками, при этом кое-где они все-таки могут использоваться. скажем, в тестах.
N>В чём удобство такой организации?
1) компилятор транслирует весь файл целиком и линкер не в состоянии "выковыривать" оттуда реально используемые функции;
2) если у нас есть только один файл, то в общем случае мы нагружаем только одно ядро ЦП (большинство компиляторов однопоточные), а вот множество файлов могут транслироваться параллельно;
3) при изменении большого файла компилятор вынужден транслировать кучу кода, который не был изменен, но компилятор об этом не знает;
N>Во-первых, можно быстро, без документации узнать что есть в библиотеке, найти функцию, о которой даже и не думал.
посмотрите как устроены штатные библиотеки компилятора. там все-таки каждая функция задвинута в свой файл. после трансляции эти файлы заворачиваются в один библиотечный файл, т.к. множество мелких файов это плохо для любой фс.
> А так: заглянул, увидел, применил.
заглянул это как? сценарий "один файл на одну функцию" -- посмотрели на имена файлов и поняли какие функции у нас есть. а так нужно парсить исходный файл.
N>Во-вторых, меньше инклудов писать руками.
как раз инклуды могут вкючать в себя другие инклуды. это не проблема
N>И, в-третьих, уже лично для меня: не надо запоминать кучу сущностей. Помнить про один файл легче, чем про 10 или 20.
вы все-таки посмотрите на сорцы того же ms vc crt.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
М>1) компилятор транслирует весь файл целиком и линкер не в состоянии "выковыривать" оттуда реально используемые функции;
Это не так. Можно сказать компилятору класть каждую функцию в свою секцию. И тогда линкер прекрасно может выбросить любую неиспользуемую функцию. Знаю несколько компиляторов это поддерживающих, и GCC среди них (-ffunction-sections). Правда иногда за это приходится платить более длинными вызовами (напривер в АРМ с -mlong-calls)
Здравствуйте, gardener, Вы писали:
М>>1) компилятор транслирует весь файл целиком и линкер не в состоянии "выковыривать" оттуда реально используемые функции;
G> Это не так. Можно сказать компилятору класть каждую функцию в свою секцию. G> И тогда линкер прекрасно может выбросить любую неиспользуемую функцию.
если ставить целью опровергунть мое высказывание, то еще глобальную оптимизацию кода можно вспомнить. но это частный случай. а в общем -- намного удобнее иметь библиотеку, созданную библиотекорем из кучи объектных файлов.
это удобнее хотя бы уже потому, что парадигма "одна функция — один файл" сильно упрощает повторное использование кода и включение его в другой проект.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
М>это удобнее хотя бы уже потому, что парадигма "одна функция — один файл" сильно упрощает повторное использование кода и включение его в другой проект.
Можно подумать, C запрещает косвенную рекурсию между функциями, описанными в разных файлах.
(...Ах да, это ж C... поправляюсь: при условии, что для f.c и g.c существуют f.h и g.h, включаемые в оба .c. Господи, я уже и забыл за давностию лет, как это удобно — заголовочные файлы! Теперь можно не по одному, а по целых два файла на функцию сделать! А если ещё и препроцессор с преподвыпертом заюзать!.. Впрочем, я отвлёкся.)
А если не запрещает, то никакого преимущества для повторной используемости это не даст: спагетти можно забабахать точно такое же что в одном файле, что в тысяче.
Кстати, хотел спросить. Часто обнаруживаю, что на озоне нет тех книг которые я хотел бы прочесть.
К примеру Таненбаума(ОС: разработка и реализация) и вот этих тоже нет. Есть ли достойная альтернатива озону(хочется в русском переводе почитать)?
Здравствуйте, -n1l-, Вы писали:
N>Кстати, хотел спросить. Часто обнаруживаю, что на озоне нет тех книг которые я хотел бы прочесть. N>К примеру Таненбаума(ОС: разработка и реализация) и вот этих тоже нет. Есть ли достойная альтернатива озону(хочется в русском переводе почитать)?
Можно смотреть my-shop и Лабиринт.
Там частенько бывает, если на озоне нет.
Можно в магазины конкретных издательств ткнуться. Например, Питер имеет собственный магазин — там, кстати, можно Таненбаума поискать.
Еще полезно в букинистический alib.ru ходить — там даже новые книги можно иногда обнаружить.
Хороший магазин urss.ru — там часто бывают научные книги, которых больше нигде нет.
И старые программистские — тоже.
Еще на Озоне можно оставить заявку на ожидание.
Когда книжка появится — вас известят.
Если заявок много — озон как-то решает этот вопрос, книжка обычно появляется.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, -n1l-, Вы писали:
N>>Кстати, хотел спросить. Часто обнаруживаю, что на озоне нет тех книг которые я хотел бы прочесть. N>>К примеру Таненбаума(ОС: разработка и реализация) и вот этих тоже нет. Есть ли достойная альтернатива озону(хочется в русском переводе почитать)? LVV>Можно смотреть my-shop и Лабиринт. LVV>Там частенько бывает, если на озоне нет. LVV>Можно в магазины конкретных издательств ткнуться. Например, Питер имеет собственный магазин — там, кстати, можно Таненбаума поискать. LVV>Еще полезно в букинистический alib.ru ходить — там даже новые книги можно иногда обнаружить. LVV>Хороший магазин urss.ru — там часто бывают научные книги, которых больше нигде нет. LVV>И старые программистские — тоже.
Спасибо огромное.
LVV>Еще на Озоне можно оставить заявку на ожидание. LVV>Когда книжка появится — вас известят. LVV>Если заявок много — озон как-то решает этот вопрос, книжка обычно появляется.
Да в курсе, только либо у них е-мэйл оповещения нет, либо я просто не успеваю купить. Помню зашел просто так на сайт, а там оповещения о том что книги есть, зашел на страницу покупки, а книг уже нема.
Я не ставил показать целью что удобнее, а что нет. Я просто указал что один из доводов как минимум имеет ограниченую область.
Выше в треде прозвучало SQLite распространяется как один файл. Я не думаю что это сильно связано с удобством компиляции. Скорее всего это из-за того, что более эффективный код генерируется — например за счет того что компилятор может агрессивно инлайнить (в моей практике link time optimizations это скорее пока экзотика), за счет того что на этапе генерации кода уже известны многие расстояния для джампов и соответственно можно использовать короткие переходы.Кстати где-то встречал компилировали насколько я помню что-то из KDE как один файл и получали более быструю систему.
Я бы сказал что одна функция на файл это не правило. Зависит. Баланс бежду удобствами и эффективностью.
G>Выше в треде прозвучало SQLite распространяется как один файл.
вот что пишут сами разработчики: http://www.sqlite.org/amalgamation.html
The core SQLite library consists of 100 files of C code (as of Version 3.8.6) in the core with 14 additional files in the FTS3 and RTREE extensions. Most of these are "source" files in the sense that they are stored in the configuration management system and are maintained directly. But 6 of the core C files are generated automatically using scripts or auxiliary programs during the compilation process. Of the 100 core files, 71 are C code and 29 are C header files.
...
We have measured performance improvements of between 5 and 10% when we use the amalgamation to compile SQLite rather than individual source files. The downside of this is that the additional optimizations often take the form of function inlining which tends to make the size of the resulting binary image larger.
кроме того надо понимать, что SQLite это "одна сущность". если же мы пишем... ну, скажем, криптобиблиотеку, то там будет набор несвязанных или слабосвязанных криптофункций. смысл держать их в одном файле?
G> Я бы сказал что одна функция на файл это не правило. Зависит. Баланс бежду удобствами и эффективностью.
о чем и речь. если я хочу заюзать чужой код, то в одном случае выберу самую быструю библиотеку из всех, чтобы рвать конкурентов, а в другом — ту, которая не требует тащить ничего лишнего в проект.
я просто поделился своими наблюдениями. что хороший код (хром, например) имеет высокую степень дробления на файлы. SQLite я не собирал, так что ничего за него не скажу. но вот лис под виртуалкой собирается по принципу — запустил и лег спать. утром проснулся и обнаружил ошибку. мммать! во всяком случае первая сборка это очень долго. потом намного быстрее. а с учетом того, что на выходе у нас далеко не один исполняемый файл, то можно вносить изменения и тут же видеть результат. экономит кучу времени.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
5-10% — это реально много. У меня выходило на нашем проекте пара процентов и все. Ну там правда все и так было прилично сгруппиовано и вынесено в инлайн хедера где надо.
Насчет времени компиляции тоже по разному. У меня компилятор на каждый запуск/файл ходил по VPN через океан за лицензией. Если много мелких файлов — то не дождешься пока проект закончится собираться.
Здравствуйте, andyag, Вы писали:
A>Это вы очень хорошо написали. Вещи очевидные, но интересно, что в явном виде обычно об этом не пишут. Я бы даже немного обобщил: у любого программиста есть какое-то количество ресурсов, которые ему при "занятиях работой" нужно раскидать по примерно такому списку направлений:
A>1. Понимание задачи (чтение, коммуникации, анализ, "постановка для себя", риски, гуглинг) A>2. Выдумывание решения (понимание "достаточно хорошего решения", риски, самокритика, эксперименты, поиск готовых решений, гуглинг, релевантный опыт) A>3. Решение задачи (написание кода, самокритика, рефакторинг, тестирование, релевантный опыт)
Очень интересно — как увеличивать свой ресурс. Вы можете конкретизировать, что понимаете под "ресурсом" программиста?
Здравствуйте, kleng, Вы писали: K>В курсе. Но каждый добавочный файл — это нехилые накладные расходы, даже если он не компилируется, а только линкуется.
+1. Ещё хочу отметить, что make, чтобы не компилировать файл, вынужден проверять его last modify timestamp.
То есть, предположим, у нас был один файл размером в 64 килобайта. Его компиляция — это два обращения на чтение — одно в MFT, второе — за данными (понятно, что контроллер диска читает данные экстентами). Мы порезали его на 70 мелких файлов (1 файл: 1 функция). Теперь его компиляция — это 70 чтений с диска (т.к. у нас нет гарантии последовательного размещения записей этих файлов в MFT). Причём это 70 чтений независимо от того, нужно ли реально перекомпилировать каждый из этих файлов — с их размерами у них есть отличный шанс целиком попасть в MFT, и мы вообще ничего не экономим. То есть на самом деле нам нужно ещё 70 обращений, чтобы проверить дату результата компиляции.
То есть в полном варианте мы говорим о:
— 1 чтение метаданных large.obj
— 1 чтение метаданных large.с
— 1 чтение данных large.c
— 1 запись данных large.obj
— 1 запись метаданных large.obj
против (предполагаем мелкое изменение ровно в одной функции):
— 70 чтений метаданных smallxxx.obj
— 70 чтений метаданных smallxxx.с
— 1 (либо даже 0, если файл маленький) чтение данных small035.c
— 1 запись данных small035.obj
— 1 запись метаданных small035.obj
итого, затраты на IO — 5:143. То есть make мелких файлов продул в 29 раз.
Понятно, что в реальности всё это скорее всего берётся из кэша; тем не менее, сборка больших мелкогранулярных проектов часто упирается в поиск изменений — стоимость сканирования директорий.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, taichiman, Вы писали:
T>Здравствуйте, andyag, Вы писали:
A>>Это вы очень хорошо написали. Вещи очевидные, но интересно, что в явном виде обычно об этом не пишут. Я бы даже немного обобщил: у любого программиста есть какое-то количество ресурсов, которые ему при "занятиях работой" нужно раскидать по примерно такому списку направлений:
A>>1. Понимание задачи (чтение, коммуникации, анализ, "постановка для себя", риски, гуглинг) A>>2. Выдумывание решения (понимание "достаточно хорошего решения", риски, самокритика, эксперименты, поиск готовых решений, гуглинг, релевантный опыт) A>>3. Решение задачи (написание кода, самокритика, рефакторинг, тестирование, релевантный опыт)
T>Очень интересно — как увеличивать свой ресурс. Вы можете конкретизировать, что понимаете под "ресурсом" программиста?
Ресурс — это количество действий, которое программист может сделать за 1 рабочий день (или месяц), таких что каждое действие будет увеличивать прогресс по текущим задачам.
Определение какое-то не очень, но вот пример:
1. Джуниор делает 20 попыток поиска в гугле и только последняя попытка приводит к желаемому результату. Сделал "1 действие", потратил на это 10 минут.
2. Сеньор делает 2 попытки поиска в гугле, вторая попытка приводит к желаемому результату. Сделал "1 действие", потратил на это 1 минуту.
Если глупо проэкстраполировать, получается, что у сеньора ресурс в 10 раз больше, чем у джуниора. И объясняется это не тем, что он быстрее заходит в гугл или запросы быстрее вводит. Объясняется это тем, что он просто "лучше умеет искать" — он знает какие запросы писать бесполезно, а какие с большой вероятностью первой же ссылкой выдадут именно то, что нужно.
И тут, возвращаясь к "как увеличивать свой ресурс" — ответ очень простой: "нужно больше опыта". А "опыт" в свою очередь это просто способность быстро отличать движение в правильную сторону от движения не туда. Вот примеры:
1. Если есть минимальные сомнения по поводу постановки задачи, лучше обсудить это с автором задачи, а не пытаться угадать. (Хак: а ещё можно быть тем самым "автором задачи")
2. Если есть есть ощущение, что задача "не нужна", лучше сначала попытаться убедить автора, что она не нужна. (Хак: как обычно, лучше самому быть автором и не заводить такие тикеты)
3. Если есть 2 более-менее одинаковых библиотеки А и Б, при этом с Б опыта нет, лучше использовать А. (Хак: а ещё можно просто заранее иметь опыт с Б)
4. Если есть необходимость изучить что-то новое, нужно честно потратить N времени, чтобы понять масштаб, изучить то, что кажется понятным, а потом оценить сколько непонятного остаётся (Хак: а ещё можно этим заниматься дома, чтобы потом требовать на работе повышение зарплаты с аргументом "смотрите как хорошо я работаю благодаря обширным знаниям")
5. Если есть понимание, что "не справлюсь с задачей", лучше сообщить об этом как можно раньше, чем раз в неделю говорить "нужна ещё неделя" (Хак: можно сначала громко сказать, что задача очень сложная, а потом поднапрячься по 16 часов в день, и решить её — это позволит громко сказать "я решил очень сложную задачу, где моя премия?". Особенно хорошо работает, если задача не только сложная, но и важная для бизнеса.)
Все эти примеры более-менее очевидны и вроде как все о них знают, но на практике почему-то работают совсем не так, предпочитая собрать это всё в виде шишек. И вот после тысяч таких шишек появляется "достаточно хороший программист"
Здравствуйте, andyag, Вы писали:
A>Ресурс — это количество действий, которое программист может сделать за 1 рабочий день (или месяц), таких что каждое действие будет увеличивать прогресс по текущим задачам.
Ресурс это не количество действий, это время и мозг.
Здравствуйте, Ikemefula, Вы писали:
I>Почему то, что бы понять большую часть того, что ты говоришь, нужно читать эту самую книгу. Отсюда неясен вывод про мусор
Сказал человек который ничего из того что я говорю не понимает...
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, andyag, Вы писали:
A>>Ресурс — это количество действий, которое программист может сделать за 1 рабочий день (или месяц), таких что каждое действие будет увеличивать прогресс по текущим задачам.
I>Ресурс это не количество действий, это время и мозг.
Здравствуйте, WolfHound, Вы писали:
I>>Почему то, что бы понять большую часть того, что ты говоришь, нужно читать эту самую книгу. Отсюда неясен вывод про мусор WH>Сказал человек который ничего из того что я говорю не понимает...
Здравствуйте, Sinclair, Вы писали:
S> итого, затраты на IO — 5:143. То есть make мелких файлов продул в 29 раз.
С учётом того, что MFT обычно практически целиком лежит в кеше (иначе как "git status" на репо с 35к файлов отрабатывает за несколько миллисекунд?), то это явно неверное объяснение.
Проблема в том, что С/С++ используют препроцессор — #include, а значит при компиляции каждого smallxxx.c приходится препроцессить туеву хучу инклюдов. В качестве workaround PCH используют, который не всегда поддерживается, да и вообще кривовато работает.
В той же java, каждый класс — отдельный .java файл, который порождает несколько .class, но ничего страшного — работает гораздо быстрее C/C++.
Здравствуйте, dimgel, Вы писали:
D>Иногда меня обвиняют в овердизайне.
А как тогда по другому стать архитектором ПО. Плюс некоторые и не пытаются им стать, им достаточно писать маленькие программы. Опять же есть люди, которые представляют любую функциональность функцией. Причём не важно арифметическое это сложение, или CAD система с тысячей классов. Для них это одна функция, которая по их задумке приносит им некую пользу.
Излишний дизайн, то есть избыточность в проектировании ПО, на мой взгляд важный этап в повышении квалификации до новой роли.
