Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>С этими проблемами потом пользователи его продукта сталкиваются . Ежедневно, ежечасно, и в массовом масштабе.
AVK>Опять же по опыту скажу — нарекания на производительность от заказчиков явление редкое.
Может быть, у меня была уникальная работа, но от меня в первую очередь требовали производительности. Скажу больше — ради этого меня в команду и приняли. Проект уже несколько лет как был в работе, их многое не устраивало, но от меня требовали только одно — обеспечить доступ к данным с максимальной скоростью. Потому что если образец не будет обработан за 3 сек — его безжалостный тайм-шедулер просто сбросит.
Это во-первых. А во-вторых — а не кажется ли тебе, что заказчика мы сами воспитываем так, что он принимает низкое быстродействие как должное ? Почем ему знать, что здесь можно выжать, он же не специалист! Тебе автомобиль дали (допустим, ты не спец в них), он 120 выжимает, других нет — хорошо. А то, что он мог бы 160 выжимать — ты и не узнаешь. А компьютер и ПО ИМХО посложнее. Тем более что апгрейд автомобиля ему не посоветуешь, а тут все ясно — купите еще памяти, второй (третий и т.д) процессор, кластеризацию устройте и т.д. А он этому верит — специалист же советует, и хороший (без иронии говорю).
>Куда больше притензий по юзабилити, недостаточному функционалу и глюкам.
Юзабилити и недостаточный функционал — за пределами этой дискуссии, это отдельная тема. Глюки — да. Но убедительного доказательства, что расточительно написанная программа будет более безошибочной я не вижу.
Еще раз, да поймет меня тот, кто слышит (это не лично к тебе). Я не против хорошего проектирования , дизайна и т.д.
Я против бесконтрольного использования заведомо неэффективных решений под видом лучшего проектирования и т.д. Я против расточительных конструкций — независимо от того, кто их делает — программист или библиотека.
>Производительность, как это не парадоксально, почему то больше всего заботит программистов.
Эх, если бы. Боюсь, грядет век, когда она их и впрямь заботить не будет. Будут плодить монстров, жрущих память и ресурсы, медленные как черепахи , зато понятные и легко сопрвождаемые, да еще и говорить, что это, мол, главное. Как будто программы делаются не для того, чтобы они работали лучше, а для того, чтобы их модифицировать было легче.
Вообще мое настроение на этот счет назвать оптимистическим нельзя.
AVK>И даже если притензии по производительности есть, то они практически всегда определяются скоростью БД или внешних устройств, так что игры с битами и ручным управлением памятью в таких случаях ничем не помогут.
Где как. К примеру, в моем проекте заказчик вынужден был отказаться от баз данных и мне как раз поручили написать свою систему хранения информации в файле. Я удивился и спросил — почему БД не использовать ? Ответ был прост — недостаточно быстро. Надо сказать, что БД в этом проекте была константой, т.е в нее изменения не вносились вообще, она раз в 3 месяца перегенерировалась и всем рассылались новые копии. Я не поленился, запросил в ФИДО конференции по БД (RSDN тогда еще не было), от какой БД можно ждать получения данных в таком-то и таком случае за 50-70 мсек ? Меня там на смех подняли . Я и сыграл на константности данных — только поиск. А в итоге я сделал доступ в 90% случаев за 20 мсек или менее при том , что поиск практически всегда шел с wildcard, т.е. типа LIKE. На это я много времени убил
Да, здесь можно было от БД отказаться. В других случаях нельзя. И то, что при условии, что БД лимитирует, оптимизировать нет смысла — понимаю и не против. Кстати, как химик с понятием лимитирующая стадия процесса знаком не понаслышке . И поверь,оптимизировать чтение из файла путем замены двух сопутствующих операторов я тоже не призываю. а вот когда некие умники начинают из файла по одному байту читать — это уже другой разговор.
Ну а внешние устройства — тема особая.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, GlebZ, Вы писали:
GZ>>Битовыжимание — это сложный процесс которому надо долго учиться. И не только в плане алгоритмов и математики.
AVK>Видтшь ли, все это здорово. В теории. А на практике я еще не разу не сталкивался с проблемами, когда новичек писал жутко неоптимальный, но рабочий код. А вот с обратным сталкивался очень часто.
Нее, я встречал. Жутко неоптимальный, но рабочий. А неоптимальность еще состоит в том, что при изменении входных данных все валится.
Я не говорю о том, что не нужно уметь остальное. Научить писать красивый код значительно сложней. Но то, что за некоторые действия придется платить — нужно ощущать.
Возьмем ситуацию которая уже обсуждалась. Когда человек изменяет строку в цикле не через StringBuilder, то как выразился Sinclair — подлежит увольнению. Для обоснавания того, что нужно работать через StringBuilder — желательно объяснить как он работает. Или возьмем те же заморочки с производительностью через Reflector. Если программист реализовал через рефлектор некоторую важную и часто выполняемую часть программы, и получил недопустимо низкую производительность, то тут уже проблема архитектуры или алгоритмов. И легче переписать чем переделать.
Мне больше нравятся люди, которые не только знают что это работает, а которые знают — как и почему. Такие люди не только интересней, но и полезней.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Может быть, у меня была уникальная работа, но от меня в первую очередь требовали производительности.
Кто требовал? Заказчик? И когда это было?
Времена меняются, меняются приоритеты.
PD>Это во-первых. А во-вторых — а не кажется ли тебе, что заказчика мы сами воспитываем так, что он принимает низкое быстродействие как должное?
Нет, не кажется. Заказчик, он штука такая, если что не нравится он быстро уйдет к другому. Конкуренция на IT рынке очень жесткая. Вот буквально вчера общался на эту тему — куча требований, притом весьма противоречивых. Причем, когда я сказал, что реализация части запросов приведет к серьезным тормозам, мне было отвечено что плевать.
PD> Почем ему знать, что здесь можно выжать, он же не специалист!
Зато он точно знает что ему нужно.
PD> Тебе автомобиль дали (допустим, ты не спец в них), он 120 выжимает, других нет — хорошо. А то, что он мог бы 160 выжимать — ты и не узнаешь.
Если это грузовик, то хоть 200 — все равно быстрее 100 ему ездить не нужно, у него другие приоритеты — сколько груза поднимает, как часто ломается, сколько запчасти стоят и т.п.
>>Куда больше притензий по юзабилити, недостаточному функционалу и глюкам.
PD>Юзабилити и недостаточный функционал — за пределами этой дискуссии, это отдельная тема.
Да в том то и дело, что нет. Все эти вещи взаимосвязаны. В условиях ограниченных ресурсов повышение производительности возможно только за счет чего то дургого — обычно за счет функционала, надежности либо сроков. Бесплатного сыра не бывает.
PD> Глюки — да. Но убедительного доказательства, что расточительно написанная программа будет более безошибочной я не вижу.
А такого никто и не утверждает. Говорят о другом — если приоритет отдать безглючности, то глюков будет меньше, хотя бы и в ущерб производительности.
PD>Еще раз, да поймет меня тот, кто слышит (это не лично к тебе). Я не против хорошего проектирования , дизайна и т.д. PD>Я против бесконтрольного использования заведомо неэффективных решений под видом лучшего проектирования и т.д. Я против расточительных конструкций — независимо от того, кто их делает — программист или библиотека.
Видишь ли — не существует единственно хорошего, т.е. верного и правильного дизайна, это я тебе как краевед говорю. При проектировании любого куска существует множество решений и, как правило, ни одно из них не является лучшим по всем параметрам. Одно тяжелее реализовать, другое приводит к плохо масштабируемому коду, третье чревато глюками, четвертое привносит заметный оверхед и т.п. Задача архитектора — выбрать золотую середину. Так вот — золото этой середины существенно зависит от приоритетов. Если производительность нужна любой ценой, то будет выбрано одно решение, если это не так — другое.
Что же касается расточительных конструкций — очень редко бывает, что оверхед абсолютно бессмысленен. Например, Directory.GetFiles, против которой ты ополчился, на самом деле проще в использовании, нежели виндовый FindFirst/FindNext, код с ее использованием прозрачнее и чище. А если прикинуть типовой сценарий использования — проход по каталогу типичных размеров и обработка найденных файлов, то GetFiles еще и более масштабируемо, поскольку держит объекты ядра максимально короткое время. И то, что оно у тебя тормозит на каталоге из 100000 свидетельствует о нетипичности задачи (тем более что у NTFS при таком количестве мелких файлов будут большие проблемы, причем, что характерно, как раз из-за ее оптимизации). И лучшим решением было бы сменить способ хранения.
>>Производительность, как это не парадоксально, почему то больше всего заботит программистов.
PD>Эх, если бы. Боюсь, грядет век, когда она их и впрямь заботить не будет. Будут плодить монстров, жрущих память и ресурсы, медленные как черепахи , зато понятные и легко сопрвождаемые, да еще и говорить, что это, мол, главное.
Ну и что? Что в этом страшного? В конце концов, тебе шашечки или ехать? Лично мне ехать, поэтому мне не нужно максимально быстрых программ, мне нужны достаточно быстрые.
PD> Как будто программы делаются не для того, чтобы они работали лучше, а для того, чтобы их модифицировать было легче.
Работать лучше != работать быстрее. Вот например быстрый InDesign падает постоянно. И, знаешь, почему то Миша Купаев (редактор RSDN Mag) предпочел бы если бы он тормозил, чем так падать. Скажешь его тоже программисты обманули?
AVK>>И даже если притензии по производительности есть, то они практически всегда определяются скоростью БД или внешних устройств, так что игры с битами и ручным управлением памятью в таких случаях ничем не помогут.
PD>Где как. К примеру, в моем проекте заказчик вынужден был отказаться от баз данных и мне как раз поручили написать свою систему хранения информации в файле. Я удивился и спросил — почему БД не использовать ? Ответ был прост — недостаточно быстро.
Не смешно. Может он просто БД готовить не умеет?
PD>А в итоге я сделал доступ в 90% случаев за 20 мсек или менее при том , что поиск практически всегда шел с wildcard, т.е. типа LIKE. На это я много времени убил
Во-первых современные сиквел-сервера умеют в некоторых случаях для like использовать индекс. Во-вторых отсуствие full text search в конкретной БД совсем не повод отказываться от БД в качестве хранилища. Ну да бог с ней, с БД, ты только что сам признал, что все упиралось в скорость доступа к данным на диске. Для современного процессора единственное обращение к диску это вечность. Так что оптимизация кода здесь малоэффективна, нужно оптимизировать алгоритмы.
Здравствуйте, Gaperton, Вы писали:
>>> В этом коде, что я привел, ошибка. Ну не то, чтобы ошибка, но... Он >>> будет нормально работать для Events, но в общем случае не будет >>> работать корректно для CriticalSection. Тому, кто найдет ошибку, и >>> объяснит — специальный приз в виде оценки "супер".
C>>CRITICAL_SECTION — рекурсивна, Event — нет?
G>Да, но не в этом проблема. Тут прикольнее — именно вопрос реализации критической секции. Рассмотри ситуацию, когда объект в несигнальном состоянии, и на нем ждет много "процессов". Вот он переходит в сигнальное состояние, а потом обратно, а никто из "процессов" не успел получить управление. Что должно произойти в случае Event и CriticalSection?
Да, вижу, немного желающих и имеющих возможность решить эту задачку. Должно призойти следующее: все потоки, стоящие на Event, должны дружно проскочить дальше. Ну, или один — зависит от типа Event-а. В случае же критической секции ни один из потоков проскочить не должен по любому.
В этом и состоит разница между Event-ом и критической секцией. И в этом состоит ошибка в приведенной реализации WaitForAll — эта разница в функции не учтена, и код в таком виде будет работать только для Event. Впрочем, эту проблему несложно решить. Я пишу это для того, чтобы вы почувствовали, с какого рода проблемами вам придется столкнуться в случае написания планировщика.
И хочу дать совет. Это крайне интересно и увлекательно, но. Не надо пытаться сразу реализовывать все примитивы синхронизации. Добавляйте их и думайте о них по мере необходимости. Потому что необходимость в них возникает на порядок реже, чем в случае потоков — может быть, вы с ней вообще не столкнетесь.
Здравствуйте, VladD2, Вы писали:
VD>Так вот он им никогда не станет, или убъет кучу времени на вправление мозгов, если его образование начнется не с борьбы за биты. Я еще понимаю почему это получалось 10-20 лет назад. Тогда выжимание битов из байтов было актуально. Но сейчас то зачем мозги плющить этим?
Не правда Ваша.
Активно развивающиеся мобильные технологии требуют спецов битовыжимания. И это действительно современно!
Спираль замкнулась, но на другом уровне. На смену мобильным придут микро или нано технологии, перспектива для таких спецов очевидна.
Здравствуйте, vladserge, Вы писали:
V>Не правда Ваша. V>Активно развивающиеся мобильные технологии требуют спецов битовыжимания. И это действительно современно!
То-то у меня телефон на Яве.
Ну, и потребность в таких специалистах стримится к нулю.
V>Спираль замкнулась, но на другом уровне. На смену мобильным придут микро или нано технологии, перспектива для таких спецов очевидна.
В современном КПК минимум 64 метра памяти. Сравни это с топовыми пюсюками 1985-го года. Стало быть в каком-нить далеком 2020 в новейших нанодевайсах будет современные 512 метров, а то и гиг.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В современном КПК минимум 64 метра памяти. Сравни это с топовыми пюсюками 1985-го года. Стало быть в каком-нить далеком 2020 в новейших нанодевайсах будет современные 512 метров, а то и гиг.
Но, как и сегодня, кроме притивных игрулек там ничего не будет запускаться.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Может быть, у меня была уникальная работа, но от меня в первую очередь требовали производительности.
AVK>Кто требовал? Заказчик? И когда это было?
2 года назад.
AVK>Времена меняются, меняются приоритеты.
Нет, для этой задачи приоритет меняться не может. Вот если 30 GHZ у процессора будет — может, и помягче будет. 3 секунды на образец — не успел — до свидания — и вам дополнительный минус.
PD>>Это во-первых. А во-вторых — а не кажется ли тебе, что заказчика мы сами воспитываем так, что он принимает низкое быстродействие как должное?
AVK>Нет, не кажется. Заказчик, он штука такая, если что не нравится он быстро уйдет к другому. Конкуренция на IT рынке очень жесткая. Вот буквально вчера общался на эту тему — куча требований, притом весьма противоречивых. Причем, когда я сказал, что реализация части запросов приведет к серьезным тормозам, мне было отвечено что плевать.
Ну плевать так плевать.
Насчеит уйдет к другому — все не так просто.
Конечно, если другой сделает это в 2 раза более быстро работающим — да. Ну а если другой сделает примерно то же самое ? И остальные другие то же сделают ? Потому что в мире это так принято.
Страшная штука — общественное мнение. Бороться с ним почти невозможно. Все уверовали в то, что именно так и должно быть. И тот, кто скажет, что так быть не должно, в лучшем случае встретит недоуменный взгляд, а в худшем...
Помнишь сказку про голого короля ? Там все придворные делали вид, что на голом короле великолепное платье. А потом появился мальчик, который и сказал :"А король-то голый".
Так вот, я подозреваю, что дело там обстояло значительно хуже.
Когда придворные впервые увидели голого короля, они, конечно, поверили своим глазам и поняли, что король голый. Но их убеждали, что на короле шикарное платье. Вначале они посмеивались про себя — ну надо делать вид, что это так, будем делать вид. Но человек не может долго лгать самому себе. Другим — может, себе — нет. Это противоречит психологии человека. Поэтому он начинает в свою ложь верить. И спустя некоторое время эти придворные уже вполне верили, что на короле шикарное платье. Не лгали себе, а были в этом убеждены. Вопреки тому, что видели.
И когда появился мальчик и сказал свои слова, то на придворных это никакого влияния не оказало. Мальчика заперли в тюрьму или сумасшедший дом, король продолжал ходить голый, придворные восхваляли по-прежнему его наряд. Вот и все.
Не раз я с этим сталкивался в своей жизни. Делают люди явную чушь, но они ее делают давно, им никто делать, квы, не мешает, вот они и уверовали в то, что делают они нужное и полезное дело. И попробуй им сказать, что они в действительности ерундой занимаются. Да более того — попробуй им объяснить, что вместо этого делать надо (и при том, что они это делать даже смогут!). Бесполезно. Так и будут своей ерундой заниматься. Хорошо, если их ерунда на других не скажется и у них власти нет. А иначе — а впрочем, о чем тут говорить. Ты при советской власти жил ?
Я, конечно, очень далек от мысли, что те, кто делает неэффективно, занимаются ерундой. Просто они неэффективно делают, и в этом мире так принято (могу на эту тему анекдот рассказать . И далеко не всегда найдется достаточно мощная сила, которая сможет не только им сказать "вы не так делаете", но еще и мир убедить, что они не так делают. PD>> Почем ему знать, что здесь можно выжать, он же не специалист!
AVK>Зато он точно знает что ему нужно.
PD>>Еще раз, да поймет меня тот, кто слышит (это не лично к тебе). Я не против хорошего проектирования , дизайна и т.д. PD>>Я против бесконтрольного использования заведомо неэффективных решений под видом лучшего проектирования и т.д. Я против расточительных конструкций — независимо от того, кто их делает — программист или библиотека.
AVK>Что же касается расточительных конструкций — очень редко бывает, что оверхед абсолютно бессмысленен. Например, Directory.GetFiles, против которой ты ополчился, на самом деле проще в использовании, нежели виндовый FindFirst/FindNext, код с ее использованием прозрачнее и чище.
Пардон, решительно возражу. Получать всю коллекцию чего бы то ни было, когда нужен один или несколько элементов этой коллекции — не есть прозрачнее и чище. Это есть только бессмысленная трата ресурсов и ничего больше.
>А если прикинуть типовой сценарий использования — проход по каталогу типичных размеров и обработка найденных файлов, то GetFiles еще и более масштабируемо, поскольку держит объекты ядра максимально короткое время. И то, что оно у тебя тормозит на каталоге из 100000 свидетельствует о нетипичности задачи
М-да, совершенно нетипичная задача — реализовать команду dir
>(тем более что у NTFS при таком количестве мелких файлов будут большие проблемы
Не будет. Там B+ дерево. Вот у FAT, точно, будет.
>, причем, что характерно, как раз из-за ее оптимизации). И лучшим решением было бы сменить способ хранения.
Я бы и рад в рай, да грехи не пускают. Так эти данные от прибора поступают туда через ПО, которое мне не подконтрольно.
>>>Производительность, как это не парадоксально, почему то больше всего заботит программистов.
PD>>Эх, если бы. Боюсь, грядет век, когда она их и впрямь заботить не будет. Будут плодить монстров, жрущих память и ресурсы, медленные как черепахи , зато понятные и легко сопрвождаемые, да еще и говорить, что это, мол, главное.
AVK>Ну и что? Что в этом страшного? В конце концов, тебе шашечки или ехать?
Ехать, но с ветерком, а не на кляче.
>Лично мне ехать, поэтому мне не нужно максимально быстрых программ, мне нужны достаточно быстрые.
Так ведь в итоге получаются недостаточно. А когда этих недостаточно на одном РС соберется с десяток, то все тормозить начинает уж совсем неприлично.
AVK>Работать лучше != работать быстрее. Вот например быстрый InDesign падает постоянно. И, знаешь, почему то Миша Купаев (редактор RSDN Mag) предпочел бы если бы он тормозил, чем так падать. Скажешь его тоже программисты обманули?
С InDesign не знаком, так что no comment. А если уж зашла речь о RSDN, то не мог бы ты как член RSDN Team объянить наконец, почему он иногда тормозит на 30-40 секунд ? Я об этом несколько раз в "Обсуждении сайта" спрашивал, никто не отвечает. Я , конечно, не буду утверждать, что по мне бы лучше, чтобы он падал, но не тормозил, но вот то, что он тормозит, меня отнюдь не радует. Потому что в результате я трачу времени на просмотр больше, чем надо.
AVK>>>И даже если притензии по производительности есть, то они практически всегда определяются скоростью БД или внешних устройств, так что игры с битами и ручным управлением памятью в таких случаях ничем не помогут.
PD>>Где как. К примеру, в моем проекте заказчик вынужден был отказаться от баз данных и мне как раз поручили написать свою систему хранения информации в файле. Я удивился и спросил — почему БД не использовать ? Ответ был прост — недостаточно быстро.
AVK>Не смешно. Может он просто БД готовить не умеет?
Смешного мало. Утверждать, не зная задачи, что нужную производительность можно получить — я бы не стал. Кстати, когда я обратился в ФИДО конференцию по БД и описал им ситуацию, ответ был почти единодушный — ты этого с помощью БД не получишь, пиши лучше что-то свое.
PD>>А в итоге я сделал доступ в 90% случаев за 20 мсек или менее при том , что поиск практически всегда шел с wildcard, т.е. типа LIKE. На это я много времени убил
AVK>Во-первых современные сиквел-сервера умеют в некоторых случаях для like использовать индекс.
Знаю. Но только в некоторых случаях. А в общем случае — не могут.
>Во-вторых отсуствие full text search в конкретной БД совсем не повод отказываться от БД в качестве хранилища. Ну да бог с ней, с БД, ты только что сам признал, что все упиралось в скорость доступа к данным на диске. Для современного процессора единственное обращение к диску это вечность. Так что оптимизация кода здесь малоэффективна, нужно оптимизировать алгоритмы.
Именно. Только с маленькой поправкой — скорость доступа к данным на диске при том, что там данные организованы именно так, как мне лучше. Оптимизировал я именно алгоритм (там и близко никаких реляционных таблиц не было) и способ хранения, т.е структуру файла. Повлиять на скорость работы диска я не могу. а вот сделать так, чтобы время запроса было сравнимым с временем чтения с диска выборки, как если бы она там уже была готовой (а это обычно было 20-50 Кбайт, не более) — могу. И именно это я и сделал — организовал данные таким образом, что нужно было просто прочитать нужное место, ну и кое-что все же отфильтровать — и вот они на блюдечке с голубой каемочкой.
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Времена меняются, меняются приоритеты.
PD>Нет, для этой задачи приоритет меняться не может. Вот если 30 GHZ у процессора будет — может, и помягче будет. 3 секунды на образец — не успел — до свидания — и вам дополнительный минус.
Рассказал бы ты все таки что за задача такая.
PD>Насчеит уйдет к другому — все не так просто. PD>Конечно, если другой сделает это в 2 раза более быстро работающим — да. Ну а если другой сделает примерно то же самое ? И остальные другие то же сделают ? Потому что в мире это так принято.
Ты как будто меня не слышишь. Не я убеждаю заказчика, что производительность не важна. Заказчик убеждает меня, что ему нужен функционал, пусть даже работать это будет очень медленно. И если я ему скажу, что я часть его требований не выполню, зато у него все будет в 10 раз быстрее работать, то он даже разговаривать со мной не будет.
PD>Страшная штука — общественное мнение. Бороться с ним почти невозможно. Все уверовали в то, что именно так и должно быть. И тот, кто скажет, что так быть не должно, в лучшем случае встретит недоуменный взгляд, а в худшем...
Какое к черту общественное мнение? Люди приходят с вполне конкретными требованиями, которые диктуются конкретной ситуацией на их предприятиях. Им плевать на всю эту философию по поводу производительности, потому что, если что то можно сделать автоматически, то это должно быть сделано автоматически и как можно быстрее (в плане доступности решения). Даже если это будет медленнее работать, нежели сделать то же самое руками.
Поэтому ты можешь убеждать себя и других про голого короля, на заказчика это не повлияет. Потому что ему не шашечки, ему ехать. И критерий у него очень простой — вчера у него сидело 2 бабы Мани, а сегодня одна. А работа выполняется та же. Или вчера он остатки на складе получал к обеду раз в день, а сегодня в любое время, через 5 минут после нажатия кнопки. Все, на остальное ему плевать. В том числе и на покупку новых компов, потому что стоимость железок даже для небольшого предприятия ничтожна.
И еще о понятии эффективности — понятие это штука сложная. Не стоит его рассматривать только с точки зрения потребленного электричества. Надо думать и о людских ресурсах, и о стоимости разработки решения, и о времени на модернизацию и о куче других проблем. Программа сама по себе малоинтересна, интересен реальный выхлоп процесса в котором эта программа участвует.
AVK>>Что же касается расточительных конструкций — очень редко бывает, что оверхед абсолютно бессмысленен. Например, Directory.GetFiles, против которой ты ополчился, на самом деле проще в использовании, нежели виндовый FindFirst/FindNext, код с ее использованием прозрачнее и чище.
PD>Пардон, решительно возражу. Получать всю коллекцию чего бы то ни было, когда нужен один или несколько элементов этой коллекции — не есть прозрачнее и чище.
Опять ты меня не слышишь. В 90% случаев нужно получить всю коллекцию. И в этом случае GetFiles эффективнее.
>>А если прикинуть типовой сценарий использования — проход по каталогу типичных размеров и обработка найденных файлов, то GetFiles еще и более масштабируемо, поскольку держит объекты ядра максимально короткое время. И то, что оно у тебя тормозит на каталоге из 100000 свидетельствует о нетипичности задачи
PD>М-да, совершенно нетипичная задача — реализовать команду dir
Нетипичная задача — хранить 100000 файлов в одном каталоге.
>>(тем более что у NTFS при таком количестве мелких файлов будут большие проблемы
PD>Не будет. Там B+ дерево. Вот у FAT, точно, будет.
Будут. Например, с целью оптимизации доступа к мелким файлам эти файлы не занимают кластеры в основном пространстве, а храняться прямо в MFT. Это позволяет съэкономить одно позиционирование головки. Но есть одна засада — расти MFT умеет, а вот уменьшаться нет. А еще оно не умеет дефрагментироваться. В результате, из-за распухшей и фрагментированной MFT операции с диском заметно замедляются.
>>, причем, что характерно, как раз из-за ее оптимизации). И лучшим решением было бы сменить способ хранения.
PD>Я бы и рад в рай, да грехи не пускают. Так эти данные от прибора поступают туда через ПО, которое мне не подконтрольно.
Ага, вот и получается, что проблема то совсем не в БД.
>>Лично мне ехать, поэтому мне не нужно максимально быстрых программ, мне нужны достаточно быстрые.
PD>Так ведь в итоге получаются недостаточно.
Кому?
PD> А когда этих недостаточно на одном РС соберется с десяток, то все тормозить начинает уж совсем неприлично.
ВОт когда соберется, тогда и голову будем ломать. А пока что у меня софта на машине много, но особых взаимных тормозов я пока не наблюдаю.
PD> А если уж зашла речь о RSDN, то не мог бы ты как член RSDN Team объянить наконец, почему он иногда тормозит на 30-40 секунд?
Не знаю, я разработкой сайта почти не занимаюсь.
PD> Я об этом несколько раз в "Обсуждении сайта" спрашивал, никто не отвечает. Я , конечно, не буду утверждать, что по мне бы лучше, чтобы он падал, но не тормозил, но вот то, что он тормозит, меня отнюдь не радует. Потому что в результате я трачу времени на просмотр больше, чем надо.
Поставь янус.
AVK>>Не смешно. Может он просто БД готовить не умеет?
PD>Смешного мало. Утверждать, не зная задачи, что нужную производительность можно получить — я бы не стал.
БД как минимум не хуже FS. Просто если тебе нужен полнотекстовый поиск, то не стоит использовать like.
Здравствуйте, AndrewVK, Вы писали: AVK> В 90% случаев нужно получить всю коллекцию.
Вообще то в 90% случаев нужно последовательно обработать все элементы. А будут там элементы из потока (итератора) или самой коллекции, это не суть важно.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
AVK>> В 90% случаев нужно получить всю коллекцию.
ANS>Вообще то в 90% случаев нужно последовательно обработать все элементы. А будут там элементы из потока (итератора) или самой коллекции, это не суть важно.
Важно, если смотреть с точки зрения времени использования открытых хендлов ядра. Я об этом писал.
AVK>Ты как будто меня не слышишь. Не я убеждаю заказчика, что производительность не важна. Заказчик убеждает меня, что ему нужен функционал, пусть даже работать это будет очень медленно. И если я ему скажу, что я часть его требований не выполню, зато у него все будет в 10 раз быстрее работать, то он даже разговаривать со мной не будет.
Естественно. Но разве я говорил, что ради быстродействия можно поступиться функционалом ?
PD>>Страшная штука — общественное мнение. Бороться с ним почти невозможно. Все уверовали в то, что именно так и должно быть. И тот, кто скажет, что так быть не должно, в лучшем случае встретит недоуменный взгляд, а в худшем...
AVK>Какое к черту общественное мнение? Люди приходят с вполне конкретными требованиями, которые диктуются конкретной ситуацией на их предприятиях. Им плевать на всю эту философию по поводу производительности, потому что, если что то можно сделать автоматически, то это должно быть сделано автоматически и как можно быстрее (в плане доступности решения). Даже если это будет медленнее работать, нежели сделать то же самое руками.
Именно так. Эти люди не знают, что здесь можно сделать, а поэтому полагаются на нас. А мы им даем не самое эффектиыное решение. А потом им надо еще что-то сделать, и то же самое происходит. И т.д. А в итоге все тормозит или жрет ресурсы. И мы им говорим — надо апгрейд машины делать. И они делают. А мы теперь еще больше ресурсов жрем. И все повторяется.
AVK>Поэтому ты можешь убеждать себя и других про голого короля, на заказчика это не повлияет. Потому что ему не шашечки, ему ехать. И критерий у него очень простой — вчера у него сидело 2 бабы Мани, а сегодня одна. А работа выполняется та же. Или вчера он остатки на складе получал к обеду раз в день, а сегодня в любое время, через 5 минут после нажатия кнопки. Все, на остальное ему плевать. В том числе и на покупку новых компов, потому что стоимость железок даже для небольшого предприятия ничтожна.
Да, ты, конечно, прав. Только вот правота эта сводится к одной простой фразе — заказчик все слопает. Как бы мы ни сделали — лишь бы его требованиям удовлетворяло. Ну что же, в этом есть свой резон — на уровне принципа "чего изволите". Но я это все же не могу принять — я хочу помимо всего еще и сделать как следует. И это как следует не заказчиком определяется, а мной. Потому что я знаю, как здесь можно сделать, а заказчик — не знает.
AVK>И еще о понятии эффективности — понятие это штука сложная. Не стоит его рассматривать только с точки зрения потребленного электричества. Надо думать и о людских ресурсах, и о стоимости разработки решения, и о времени на модернизацию и о куче других проблем. Программа сама по себе малоинтересна, интересен реальный выхлоп процесса в котором эта программа участвует.
Не так все это просто. От задачи зависит. Скажем, делая сайт для некоторой компании — это одно, а ICQ — это другое. Насчет дкмать о людских ресурсах — ох, не уверен совсем. Представь себе, что по такому пути автомобилестроители пойдут — не важно, сколько бензина автомобиль сжигает, надо ведь и о людских ресурсах, которые пошли на его разработку, подумать. Фирма с таким подходом в трубу там вылетит.
PD>>Пардон, решительно возражу. Получать всю коллекцию чего бы то ни было, когда нужен один или несколько элементов этой коллекции — не есть прозрачнее и чище.
AVK>Опять ты меня не слышишь. В 90% случаев нужно получить всю коллекцию. И в этом случае GetFiles эффективнее.
Эффективнее оно быть не может, потому хотя бы, что внутри себя вызывает FindFirst/NextFile . А насчет 90% — сомневаюсь. Вот тебе еще пример
The InstalledFontCollection class defines a class that represents the fonts installed on the system.
Скажи, пожалуйста, для каких задач мне может понадобиться узнать все шрифты. установленные в системе.
>>>А если прикинуть типовой сценарий использования — проход по каталогу типичных размеров и обработка найденных файлов, то GetFiles еще и более масштабируемо, поскольку держит объекты ядра максимально короткое время.
Если мне понадобится, я их тоже буду держать максимально короткое время. Потому как написать для меня GetFiles ничего не стоит. А с другой стороны , я полумаю, что мне важнее — один лишний хендл, от которого мне ни холодно ни жарко вообще-то, или лишних 50 Мбайт.
AVK>Нетипичная задача — хранить 100000 файлов в одном каталоге.
Пусть так. Но ведь нет же средства, вообще нет (без InterOp) решить эту, пусть нетипичную задачу.
AVK>Будут. Например, с целью оптимизации доступа к мелким файлам эти файлы не занимают кластеры в основном пространстве, а храняться прямо в MFT. Это позволяет съэкономить одно позиционирование головки. Но есть одна засада — расти MFT умеет, а вот уменьшаться нет. А еще оно не умеет дефрагментироваться. В результате, из-за распухшей и фрагментированной MFT операции с диском заметно замедляются.
Ну и что ? Какое это отношение к делу имеет ? Если я эти 100000 файлов по 100 каталогам разбросаю, что, размер MFT изменится или степень дефрагментированности ее ?
AVK>Ага, вот и получается, что проблема то совсем не в БД.
Нет. Это никакого отношения к БД не имело. БД — совсем другая часть задачи, а 100000 файлов — это просто тестовый набор образцов.
PD>>Так ведь в итоге получаются недостаточно.
AVK>Кому?
Мне.
PD>> Я об этом несколько раз в "Обсуждении сайта" спрашивал, никто не отвечает. Я , конечно, не буду утверждать, что по мне бы лучше, чтобы он падал, но не тормозил, но вот то, что он тормозит, меня отнюдь не радует. Потому что в результате я трачу времени на просмотр больше, чем надо.
AVK>Поставь янус.
Не имел с ним дела. Подумаю.
AVK>БД как минимум не хуже FS. Просто если тебе нужен полнотекстовый поиск, то не стоит использовать like.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, gear nuke, Вы писали:
GN>>Здравствуйте, VladD2, Вы писали:
GN>>Я тоже интересуюсь всякой такой ерундой. Причина проста — знаю очень мало. Это на Спектруме было понятно зачем каждый байт нужен, а теперь, когда в окружении многих других программ запускается и даже работает моя, первая мысль: "ух как повезло" .
S>А вот у меня был Speccy какой точно не помню, но прерывания у него были реализованы — мама-не-горюй...
да ладно, всё просто там было. в регистр I грузится старший байт адреса талицы прерываний. Младший байт берётся с шины данных в момент прихода прерывания. Задумка архитектуры проца отличная — возможность железкой выбирать нужное прерывание. На большинстве пост-советских клонов на шине адреса всегда был #FF — в момент прихода прерывания проц брал адрес обработчика из адреса regI * 256 + #FF Всё очень просто!
Но ещё был вопрос совместимости
На оригинальных Speccy и на некоторых клонах в момент прерывания на шине данных был мусор. В этом случае фигачили таблицу размером в 257 байт, выровненную на 256 байт в памяти, т.к. "мусорная" составляющая адреса вызывала колебание на адреса в таблице обработчиков в пределах 256 байт. Заполняли таблицу одинаковыми байтами (напр. #BE). Обработчик размещали, соотв. по адресу #BEBE
вот и вся обработка прерываний на Speccy (режим IM2)
А вот если почитать о прерываниях на x86 — там всё гораздо сложнее
Лирическое отступление:
Павел, ты уж извини, но разговор в таком стиле лишен смысла. Ты либо учитывай то что я писал, либо я не буду тратить бестолку время.
PD>Естественно. Но разве я говорил, что ради быстродействия можно поступиться функционалом ?
Помнишь что я писал про многофакторность выбора оптимального решения?
PD>Именно так. Эти люди не знают, что здесь можно сделать, а поэтому полагаются на нас. А мы им даем не самое эффектиыное решение. А потом им надо еще что-то сделать, и то же самое происходит. И т.д. А в итоге все тормозит или жрет ресурсы.
Прочти то, что я писал про эффективность.
PD>Да, ты, конечно, прав. Только вот правота эта сводится к одной простой фразе — заказчик все слопает.
Где я такое писал? Я писал прямо обратное — заказчик не хочет лопать сверхпроизводительные решения, он хочет лопать достаточно производительные и максимально функциональные, причем, что характерно, вчера.
PD> Как бы мы ни сделали — лишь бы его требованиям удовлетворяло. Ну что же, в этом есть свой резон — на уровне принципа "чего изволите". Но я это все же не могу принять — я хочу помимо всего еще и сделать как следует.
Делай. Но за собственные деньги, а не за деньги заказчика. Представь, что ты приехал на сервис сменить летнюю резину на зимнюю. Оставил машину утречком, а вечером приходишь, а тебе и говорят — во-первых машина не готова, а во-вторых с вас 1000 баксов. Ты им — как твк, резину перемонтировать работы на полчаса и 20 баксов. А они тебе в ответ — тут у тебя чего то мотор еще барахлил, амортизаторы подсели, на крыле вмятина, на заднем стекле пару дорожек обогревателя не работают, аккумулятор старенький и т.д. Так мы решили все по совести сделать.
А теперь, внимание, вопрос — поедешь лы ты в такой сервис еще раз резину менять?
PD> И это как следует не заказчиком определяется, а мной. Потому что я знаю, как здесь можно сделать, а заказчик — не знает.
Зато заказчик знает сколько у него денег и сколько времени он готов терпеть.
PD>Не так все это просто.
Это у тебя все просто — мало ресурсов программа кушает, значит это безусловно хорошо. А на практике все совсем не так.
PD> От задачи зависит. Скажем, делая сайт для некоторой компании — это одно, а ICQ — это другое.
Вот об этом я тебе и говорю — выбор эффективного решения штука многофакторная и потребление ресурсов программой далеко не самое важное.
PD>Насчет дкмать о людских ресурсах — ох, не уверен совсем.
Если бы я был заказчик, то, после этой фразы, разговор был бы окончен.
PD> Представь себе, что по такому пути автомобилестроители пойдут — не важно, сколько бензина автомобиль сжигает, надо ведь и о людских ресурсах, которые пошли на его разработку, подумать.
А ты чего думаешь, они об этом не думают? Там сейчас все очень жестко — не сумеешь вовремя выпустить новые машины, вмиг вылетишь с рынка. И думают они не только о расходе бензина, а еще и о комфорте, надежности, дизайне, удобстве, функционале, ремонтопригодности, возможности предложить широчайший выбор опций, и, как это не удивительно, о возможности модернизации. Не секрет, что многие модели 2005 года ведут родословную от автомобилей 20-30летней давности. Т.е. новый автомобиль никто не проектирует с нуля, а, пользуясь заложенными на начальном проектировании запасами, модернизируют старый. До тех пор пока потенциал модернизации не будет исчерпан.
Да что там автомобили. Даже у современных истребителей, которые, казалось бы, должны создаваться на пределе возможного, тем не менее фактор модернизируемости при проектировании один из важнейших.
AVK>>Опять ты меня не слышишь. В 90% случаев нужно получить всю коллекцию. И в этом случае GetFiles эффективнее.
PD>Эффективнее оно быть не может
Читай еще раз что я писал об эффективности.
PD>, потому хотя бы, что внутри себя вызывает FindFirst/NextFile .
Ну и что? Ты помнишь что я писал про время использования объектов ядра? Так вот, с точки зрения масштабируемости решения лучше быстро перебрать, а потом уже ковыряться с файлами, нежели медленно ползти по директории.
PD> А насчет 90% — сомневаюсь.
Ну вот тем не менее за последние 10 лет лично мне ни разу не приходилось читать директории, в которых 100К файлов.
PD>The InstalledFontCollection class defines a class that represents the fonts installed on the system.
PD>Скажи, пожалуйста, для каких задач мне может понадобиться узнать все шрифты. установленные в системе.
Для выбора шрифта из списка. И тебя есть другие варианты применения?
PD>Если мне понадобится, я их тоже буду держать максимально короткое время.
Но при этом формировать буфер тебе придется вручную. В итоге — код больше, сложнее, да еще и помнить надо постоянно о масштабируемости.
AVK>>Нетипичная задача — хранить 100000 файлов в одном каталоге.
PD>Пусть так. Но ведь нет же средства, вообще нет (без InterOp) решить эту, пусть нетипичную задачу.
А чем тебя интероп не устраивает? Нормальное средство.
AVK>>Будут. Например, с целью оптимизации доступа к мелким файлам эти файлы не занимают кластеры в основном пространстве, а храняться прямо в MFT. Это позволяет съэкономить одно позиционирование головки. Но есть одна засада — расти MFT умеет, а вот уменьшаться нет. А еще оно не умеет дефрагментироваться. В результате, из-за распухшей и фрагментированной MFT операции с диском заметно замедляются.
PD>Ну и что ? Какое это отношение к делу имеет ?
Обыкновенное. Ты неэфективно используешь ресурс. Хранить все данные в небольшом количестве файлов эффективнее. Ты ведь за это борешься, а сам такие ляпы допускаешь.
PD>Если я эти 100000 файлов по 100 каталогам разбросаю, что, размер MFT изменится или степень дефрагментированности ее ?
Нет.
AVK>>Ага, вот и получается, что проблема то совсем не в БД.
PD>Нет. Это никакого отношения к БД не имело. БД — совсем другая часть задачи, а 100000 файлов — это просто тестовый набор образцов.
Вот я и говорю — крайне неэффективное решение.
Пишите свои программы эффективно, господа! По крайней мере настолько, насколько это возможно!
Ась?
AVK>>БД как минимум не хуже FS. Просто если тебе нужен полнотекстовый поиск, то не стоит использовать like.
PD>Да какой-там к богу полнотекстовый поиск!
А like по твоему что делает? Вот, кстати, еще один пример, когда ты не следуешь собственным лозунгам. Вместо специализированных решений использовал примитивный like, а оказались БД виноваты.
P.S. По поводу эволюции взглядов на достижение эффективности тебе, думаю, небезынтересно будет прочесть сообщение Re[8]: Как-бы продолжение...
Здравствуйте, AndrewVK, Вы писали:
AVK>Лирическое отступление: AVK>Павел, ты уж извини, но разговор в таком стиле лишен смысла. Ты либо учитывай то что я писал, либо я не буду тратить бестолку время.
Похоже, что да. Можно и прекратить. Поскольку мы взаимно, похоже, не слышим друг друга. Поэтому отвечаю только на то, на что считаю необходимым ответить — так сказать, не могу пропустить
PD>>Да, ты, конечно, прав. Только вот правота эта сводится к одной простой фразе — заказчик все слопает.
AVK>Где я такое писал? Я писал прямо обратное — заказчик не хочет лопать сверхпроизводительные решения, он хочет лопать достаточно производительные и максимально функциональные, причем, что характерно, вчера.
Мне трудно объяснять в десятый раз, когда меня понять не хотят упорно. Я еще раз повторяю — заказчик получает представление о том, что здесь хорошо, а что плохо — на основании того, как это здесь делается. На основании текущего уровня. Если конечно, это не заказчик, который вчера компьютеры увидел. Если он хоть несколько лет с ними работает — у него сформировались представления о том, что и как здесь должно быть. Мы их сформировали. О том, что он мог бы запросить более эффективное решение, он и не догадывается, точно так же, как потребители Фордов 1930 года не могли затребовать современную машину с меньшим расходом бензина.
PD>> Как бы мы ни сделали — лишь бы его требованиям удовлетворяло. Ну что же, в этом есть свой резон — на уровне принципа "чего изволите". Но я это все же не могу принять — я хочу помимо всего еще и сделать как следует.
AVK>Делай. Но за собственные деньги, а не за деньги заказчика. Представь, что ты приехал на сервис сменить летнюю резину на зимнюю. Оставил машину утречком, а вечером приходишь, а тебе и говорят — во-первых машина не готова, а во-вторых с вас 1000 баксов. Ты им — как твк, резину перемонтировать работы на полчаса и 20 баксов. А они тебе в ответ — тут у тебя чего то мотор еще барахлил, амортизаторы подсели, на крыле вмятина, на заднем стекле пару дорожек обогревателя не работают, аккумулятор старенький и т.д. Так мы решили все по совести сделать.
AVK>А теперь, внимание, вопрос — поедешь лы ты в такой сервис еще раз резину менять?
Так он барахлил или нет ?
Аккумуляторы сели или нет ?
Вмятина была ?
И стоит ли вся эта работа 1000$ ?
Если все, что они сделали, действительно по делу, а не чтобы деньги слупить, если после этого машина пройдет 100 тыс км без обращения к ним, а иначе бы не прошла — приеду. Правда, лучше, если бы они не слепили бы с меня $1000 post factum, а честно сказали бы — так мол и так, заплатите нам $1000, зато потом гарантируем 100000 км без сучка и задоринки, а иначе мотор через 100 км забарахлит, аккумулятор сядет и т.д. PD>> И это как следует не заказчиком определяется, а мной. Потому что я знаю, как здесь можно сделать, а заказчик — не знает.
AVK>Зато заказчик знает сколько у него денег и сколько времени он готов терпеть.
Мы не договоримся, Andrew. Не он знает, а мы ему это представление сформировали своей деятельностью. Он вообще-то ничего не знает. Он свои дела знает (бизнес и т.д.), а в ИТ он знает то, что ему сфера ИТ навяжет. Как и мы знаем с тобой про самолеты, если, конгечно, ты еще и не специалист по воздухоплаванию
AVK>Это у тебя все просто — мало ресурсов программа кушает, значит это безусловно хорошо. А на практике все совсем не так.
Да нет же, совсем не так. Ну почему вы все меня никак понять не хотите ? Я высказался — пишите эффективнее. Мне в ответ — да он призывает к эффективности любой ценой! Не призываю я любой ценой! И готов платить ресурсами, если это надо. Я же не к этому призываю, а к неиспользованию заведомо неэффективных решений, аргументируя это то ли тем, что они проще, то ли тем, что так, мол, библиотека устроена, то ли еще чем. Ну скажи на милость, ты ведь не первый год в ИТ, положа руку на сердце — неужели FindFirst так уж впрямь нарушит дизайн, архитектуру и т.д. ? Ну несерьезно же такое утверждать! Это же 5 минут программирования, и никак ни на каком дизайне не скажется. Мелочь это просто, вот и все. А это решение навязывается библиотекой, и его будут использовать без всякого Интеропа те, кто про Win32 и не слышал, а их все больше будет. Вот это мне и не нравится. Вы отдаете себе отчет, что вы в .Net создаете новый мир программирования ? Отнюдь не Win32 мир с расширениями! И использовать там ИнтерОп большинство будет через некоторое время не больше, чем вызовы WinAPI в VB — тоже ведь не запрещено. И эти новые адепты будут использовать эти неэффективные решения просто потому, что они другого не знают, их этому не учили. а тогда поздно будет что-то менять — общественное мнение сложилось, именно так и надо, именно так и хорошо.
А ты мне — он призывает оптимизировать любой ценой!
AVK>Вот об этом я тебе и говорю — выбор эффективного решения штука многофакторная и потребление ресурсов программой далеко не самое важное.
Да согласен я, согласен. Ну не призываю я любой ценой
PD>>Насчет дкмать о людских ресурсах — ох, не уверен совсем.
AVK>Если бы я был заказчик, то, после этой фразы, разговор был бы окончен.
Твое право. Но, боюсь, когда речь идет о серьезных компаниях по разработке и производству чего бы то ни было. там на первом месте качество продукции, а не то, сколько на это рабочих надо. Нет рабочих или нет денег их набрать — не беритесь. А вот если хотите сэкономить на их труде и за счет этого выпустить продукцию хуже, чем у конкурента — вылетите в трубу.
А заказчик здесь вообще-то ни при чем. Не интересует меня как потенциального заказчика, сколько рабочих у Тойоты и как они оплачиваются. Меня только качество Тойоты интересует и стоимость. Не можете делать за такую же цену и не хуже по качеству, чем у конкурента — у него и куплю. Так что заказчик только деньги платит, а сколько платить — конкуренцией определяется.
PD>> Представь себе, что по такому пути автомобилестроители пойдут — не важно, сколько бензина автомобиль сжигает, надо ведь и о людских ресурсах, которые пошли на его разработку, подумать.
AVK>А ты чего думаешь, они об этом не думают? Там сейчас все очень жестко — не сумеешь вовремя выпустить новые машины, вмиг вылетишь с рынка. И думают они не только о расходе бензина, а еще и о комфорте, надежности, дизайне, удобстве, функционале, ремонтопригодности, возможности предложить широчайший выбор опций, и, как это не удивительно, о возможности модернизации. Не секрет, что многие модели 2005 года ведут родословную от автомобилей 20-30летней давности. Т.е. новый автомобиль никто не проектирует с нуля, а, пользуясь заложенными на начальном проектировании запасами, модернизируют старый. До тех пор пока потенциал модернизации не будет исчерпан.
Именно. На 101% согласен. Обо всем этом они думают, это и есть то, что я называю эффективностью, просто там критерии иные. Но вот о том, во что это им обойдется — они, конечно, думают, но нам не сообщают. А мы — заявляем на весь мир, что мол, деньги нам платят не только за то, что мы хороший продукт делаем, а и за то, что нам так удобнее делать, даже если в итоге продукт и хуже получается.
PD>>Эффективнее оно быть не может
AVK>Читай еще раз что я писал об эффективности.
PD>>, потому хотя бы, что внутри себя вызывает FindFirst/NextFile .
AVK>Ну и что? Ты помнишь что я писал про время использования объектов ядра? Так вот, с точки зрения масштабируемости решения лучше быстро перебрать, а потом уже ковыряться с файлами, нежели медленно ползти по директории.
Ох, совсем не уверен на 100%. Но пусть ты прав. В 90% случаев пусть так лучше. В 10% случаев так не лучше. Вопрос : Почему авторы FW не дали оба механизма ? Ведь дали бы — я бы слова не сказал, а сказал бы — меня просто в RTFM послали бы.
AVK>Ну вот тем не менее за последние 10 лет лично мне ни разу не приходилось читать директории, в которых 100К файлов.
А мне приходилось. Их со сканера читали и туда заносили, и я тут абсолютно ничего не смог бы сделать, если бы даже и хотел.
PD>>Скажи, пожалуйста, для каких задач мне может понадобиться узнать все шрифты. установленные в системе.
AVK>Для выбора шрифта из списка. И тебя есть другие варианты применения?
Нет. У меня вообще для получения всех нет применений никаких. Если уж нужно выбрать шрифты, ничего не зная о них, то ИМХО надо перебирать по одному, пока не найдешь нужный, а после этого прекратить.
Вот пришел ты в библиотеку (не компьютерную , и говоришь — нужна мне книга, автора не знаю, названия не знаю, год выпуска не знаю, знаю только, что она о Delphi и что она одна-единственная мне нужна. Ведут тебя к полке, где у них сотня книг по Delphi стоит и говорят — берите все, потом отберете нужную. Или все же лучше будет, если у этой полки тебе скажут — посмотрите первую, если это не то, посмотрите вторую и т.д. Я ведь все могу и не поднять
PD>>Если мне понадобится, я их тоже буду держать максимально короткое время.
AVK>Но при этом формировать буфер тебе придется вручную. В итоге — код больше, сложнее, да еще и помнить надо постоянно о масштабируемости.
Andrew, ну несерьезно же. Ты сам это код же писал — какой там к черту больше кода, там его 5 строчек. наконец, если уж так приспичит. напишу GetFiles сам, если решу. что здесь именно это и надо. Или у вас возьму. Но дайте же мне возможность выбора!
AVK>А чем тебя интероп не устраивает? Нормальное средство.
См. выше, что я написал о нем.
AVK>>>Будут. Например, с целью оптимизации доступа к мелким файлам эти файлы не занимают кластеры в основном пространстве, а храняться прямо в MFT. Это позволяет съэкономить одно позиционирование головки. Но есть одна засада — расти MFT умеет, а вот уменьшаться нет. А еще оно не умеет дефрагментироваться. В результате, из-за распухшей и фрагментированной MFT операции с диском заметно замедляются.
PD>>Ну и что ? Какое это отношение к делу имеет ?
AVK>Обыкновенное. Ты неэфективно используешь ресурс. Хранить все данные в небольшом количестве файлов эффективнее. Ты ведь за это борешься, а сам такие ляпы допускаешь.
Эти файлы туда сканер засылает. Эти файлы фотографиями явялются, которые нам обрабатывать надо ! Какой там к богу ляп — это входные данные программы.
И чего тебе так меня хочется ущучить — что я ляпы, мол, допускаю ? Ну предположим на минуту, именно я их допускаю. Допутим, я программист никуда не годный, к эффективности призваю, а сам эффективно делать не умею. От этого что, мои выводы как-то зависят ? Если это так — это лишь меня характеризует как программиста, а к моим высказываниям отношения не имеет.
А если уж тебя это так интересует — да, наверное, и не самые эффективные решения порой применяю. Может, чего-то не знаю, может, где-то не додумал. Не бог я. Вот Sinclair меня поймал на том. что я неверно оценил возможности scasd — спасибо ему за это, буду знать. Но все же пытаюсь делать как лучше, ну а что уж получается — в меру моих способностей и знаний
PD>>Если я эти 100000 файлов по 100 каталогам разбросаю, что, размер MFT изменится или степень дефрагментированности ее ?
AVK>Нет.
AVK>>>Ага, вот и получается, что проблема то совсем не в БД.
PD>>Нет. Это никакого отношения к БД не имело. БД — совсем другая часть задачи, а 100000 файлов — это просто тестовый набор образцов.
AVK>Вот я и говорю — крайне неэффективное решение.
Еще раз — это входные данные. Это не решение вообще.
AVK>
Пишите свои программы эффективно, господа! По крайней мере настолько, насколько это возможно!
AVK>Ась?
Именно. Кстати, не забудь насколько это возможно. Я не зря это сказал.
AVK>А like по твоему что делает? Вот, кстати, еще один пример, когда ты не следуешь собственным лозунгам. Вместо специализированных решений использовал примитивный like, а оказались БД виноваты.
Опять-таки — не использовал я like. Я там бог знает что закрутил, такого ни в какой теории БД нет, потому как и назвать свою разработку БД я не могу, просто это некая структура файла.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мне трудно объяснять в десятый раз, когда меня понять не хотят упорно. Я еще раз повторяю — заказчик получает представление о том, что здесь хорошо, а что плохо — на основании того, как это здесь делается.
Ты можешь сколь угодно говорить халва, но слаще от этого во рту не станет. Я таких заказчиков не видел. Я видел других, которые предпочитают все измерять деньгами и сроками.
PD>Так он барахлил или нет ?
Барахлил.
PD>Аккумуляторы сели или нет ?
Да.
PD>Вмятина была ?
Да.
PD>И стоит ли вся эта работа 1000$ ?
Наверное.
PD>Если все, что они сделали, действительно по делу, а не чтобы деньги слупить, если после этого машина пройдет 100 тыс км без обращения к ним, а иначе бы не прошла — приеду.
Да? А вот теперь подумай о другом — машина была на ходу и еще бы не одну тысячу километров проехала. И ты рассчитывал уехать на следующий день в деревню к родным. И 1000 баксов у тебя нету и даже 500 тоже нету. В результате ты и без денег и без машины, потому что пока ты недостающие деньги не найдешь и пока они после этого ее до ума не доведут, ездить ты не сможешь. На лицо убытки.
PD>Мы не договоримся, Andrew. Не он знает, а мы ему это представление сформировали своей деятельностью.
Глупости. Ему плевать на все эти представления. Ему другое важно. Сколько денег он должен вложить и какой и когда он из этих денег получит выхлоп. И если ты его начнешь басенками про голого короля кормить, он вежливо с тобой раскланяется и пойдет к другому, который такой ерундой заниматься не будет.
Более того, даже понять какой эффект он получит от программы непросто. И, если фирма достаточно крупная, он не с тобой будет на эту тему разговаривать, а с другими фирмами, занимающимися консалтингом.
И в этой схеме рассказы про эффективное использование памяти ... Ну, вобщем, просто смешно.
PD> Он вообще-то ничего не знает. Он свои дела знает (бизнес и т.д.), а в ИТ он знает то, что ему сфера ИТ навяжет. Как и мы знаем с тобой про самолеты, если, конгечно, ты еще и не специалист по воздухоплаванию
Я тебе больше скажу — он и знать не хочет. И тебя, если ты попытаешься рассказать, он слушать не будет. Ему это не надо.
AVK>>Это у тебя все просто — мало ресурсов программа кушает, значит это безусловно хорошо. А на практике все совсем не так.
PD>Да нет же, совсем не так. Ну почему вы все меня никак понять не хотите ? Я высказался — пишите эффективнее.
В очередной раз напоминаю о том, что я писал про эффективность. Эффективность штука эфемерная до тех пор, пока мы не определим критерии эффективности.
PD> Мне в ответ — да он призывает к эффективности любой ценой! Не призываю я любой ценой!
Пишите свои программы эффективно, господа! По крайней мере настолько, насколько это возможно!
Настолько, насколько возможно это и есть любой ценой.
PD> И готов платить ресурсами, если это надо.
А когда надо? Как определить — является ли потеря ресурсов допустимой при том выигрыше, который достигнут? Может ли быть код эффективен абсолютно, или эффективность зависит от поставленных задач? На каком уровне программной системы мы можем определится с критериями эффективности? Что предпочесть — эффективность здесь и сейчас или масштабируемость? Сколько времени можно потратить, чтобы сделать код эффективнее? Что лучше — потратить много памяти и мало процессора или наоборот? Стоит ли делать алгоритмы эффективными на конкретном оборудовании, или на каком то классе оборудования?
Пока ты не ответишь на эти вопросы, твои призывы к эффективности ничего не стоят. Т.е. совсем ничего.
PD> Я же не к этому призываю, а к неиспользованию заведомо неэффективных решений
Как их определить? Вот ответь мне на простой вопрос — что эффективнее, LinkedList или ArrayList?
PD>неужели FindFirst так уж впрямь нарушит дизайн, архитектуру и т.д. ?
Архитектуру нет, а вот масштабируемость запросто. А если еще вспомнить, что новички обязательно забудут FindClose позвать или в try..catch обернуть, то получим еще и утечку ресурсов ядра, а это очень неприятно.
Результат знаешь какой — если я увижу FF/FN в коде новичка, то я ни за что не рискну встроить его код в ядро сервера приложений без тщательнейшего контроля. А вот с GetFiles рискну, потому что никакой засады с его стороны я не ожидаю.
PD> Ну несерьезно же такое утверждать! Это же 5 минут программирования, и никак ни на каком дизайне не скажется. Мелочь это просто, вот и все.
Черт, он как известно в мелочах.
PD> Вы отдаете себе отчет, что вы в .Net создаете новый мир программирования ? Отнюдь не Win32 мир с расширениями!
С чего ты взял? WinAPI в дотнете будет использоваться еще очень и очень долго, особенно на клиенте.
PD>И эти новые адепты будут использовать эти неэффективные решения просто потому, что они другого не знают, их этому не учили. а тогда поздно будет что-то менять — общественное мнение сложилось, именно так и надо, именно так и хорошо.
Ты не переживай за них. Они, если действительно припрет, очень быстро обожгутся и узнают про чудесные FindFirst/FindNext. Только вот, веришь, за 4 года программирования под .NET еще ни разу не понадобилось.
Зато я в очередной раз убедился в другом — я весьма редко, несмотря на опыт, угадываю в реальных приложениях узкие места. Засада оказывается совсем не там, где я ее жду. А новички, о которых ты говоришь, вобще не угадают в 90% случаев. В результате масса усилий по оборачиванию того же FF/FN и танцам с бубном вокруг незакрытых хендлов пойдет коту под хвост. А ты ведь именно это советуешь.
Слышал наверное фразу, которую приписывают то Хоару, то Кнуту — "Premature optimization is the root of all evil (or at least most of it) in programming"? Так вот — это не шутка, а чистейшая правда.
AVK>>Вот об этом я тебе и говорю — выбор эффективного решения штука многофакторная и потребление ресурсов программой далеко не самое важное.
PD>Да согласен я, согласен. Ну не призываю я любой ценой
А какой ценой ты тогда призываешь? Если ты цену не укажешь, то твой призыв равносилен призыву за мир во всем мире. Здорово, но абсолютно абстрактно.
AVK>>Если бы я был заказчик, то, после этой фразы, разговор был бы окончен.
PD>Твое право. Но, боюсь, когда речь идет о серьезных компаниях по разработке и производству чего бы то ни было. там на первом месте качество продукции, а не то, сколько на это рабочих надо. Нет рабочих или нет денег их набрать — не беритесь. А вот если хотите сэкономить на их труде и за счет этого выпустить продукцию хуже, чем у конкурента — вылетите в трубу.
Не хочу даже обсуждать.
PD>А заказчик здесь вообще-то ни при чем. Не интересует меня как потенциального заказчика, сколько рабочих у Тойоты и как они оплачиваются. Меня только качество Тойоты интересует и стоимость.
Во, а стоимость слагается в том числе и из стоимости R&D, которая, в свою очередь, напрямую зависит от того, сколько высококвалифицированного персонала и какое время работало над этим. А если еще, к тому же, вспомнить, что доля этого самого R&D в ПО огромна ...
PD>Именно. На 101% согласен. Обо всем этом они думают, это и есть то, что я называю эффективностью, просто там критерии иные.
Во как. Значит все таки от критериев эффективность зависит. Замечательно. Теперь можно идти дальше. Кто, по твоему, и на каком уровне определяет эти критерии?
PD>А мы — заявляем на весь мир, что мол, деньги нам платят не только за то, что мы хороший продукт делаем, а и за то, что нам так удобнее делать, даже если в итоге продукт и хуже получается.
Маркетинг это совсем отдельный разговор. Если придерживаться технической стороны дела, то очевидно, что ты при покупке машины платишь в том числе и за разработку следующей модели.
AVK>>Ну и что? Ты помнишь что я писал про время использования объектов ядра? Так вот, с точки зрения масштабируемости решения лучше быстро перебрать, а потом уже ковыряться с файлами, нежели медленно ползти по директории.
PD>Ох, совсем не уверен на 100%. Но пусть ты прав. В 90% случаев пусть так лучше. В 10% случаев так не лучше. Вопрос : Почему авторы FW не дали оба механизма ?
Дали. Называется интероп. Можно ли было еще и итератор дать? Можно. Но тогда надо помнить, что при прямом отображении на FF/FN этот итератор будет неуправляемым ресурсом, что создает дополнительную нагрузку на GC (финализатор), либо требует от программиста повышенного внимания (не забыть вызвать FindClose, да еще и внутри try..catch). Ну а в МС посчитали, что те 10%, кому очень дано, спокойно воспользуются интеропом. Тебе не нравится? Твое право. Но называть это решение абсолютно неэффективным я бы не стал.
AVK>>Ну вот тем не менее за последние 10 лет лично мне ни разу не приходилось читать директории, в которых 100К файлов.
PD>А мне приходилось. Их со сканера читали и туда заносили, и я тут абсолютно ничего не смог бы сделать, если бы даже и хотел.
Ну вот и приходим к выводу, что собака неэффективности порылась отнюдь не в GetFiles, а в дурацком ПО сканера, которое на первый взгляд эффективно.
AVK>>Для выбора шрифта из списка. И тебя есть другие варианты применения?
PD>Нет. У меня вообще для получения всех нет применений никаких. Если уж нужно выбрать шрифты, ничего не зная о них, то ИМХО надо перебирать по одному, пока не найдешь нужный, а после этого прекратить.
Можно реальный пример? На основании чего ты шрифт будешь подбирать?
PD>Andrew, ну несерьезно же. Ты сам это код же писал — какой там к черту больше кода, там его 5 строчек. наконец, если уж так приспичит. напишу GetFiles сам, если решу. что здесь именно это и надо. Или у вас возьму. Но дайте же мне возможность выбора!
А у тебя он есть — интероп в зубы и вперед.
AVK>>А чем тебя интероп не устраивает? Нормальное средство.
PD>См. выше, что я написал о нем.
Не, ты написал про каких то гипотетических новичков, которые интероп осилить не могут. А вот чем тебя лично он не устраивает?
AVK>>Обыкновенное. Ты неэфективно используешь ресурс. Хранить все данные в небольшом количестве файлов эффективнее. Ты ведь за это борешься, а сам такие ляпы допускаешь.
PD>Эти файлы туда сканер засылает.
Как? Прямо на диск посредством DMA?
PD>И чего тебе так меня хочется ущучить — что я ляпы, мол, допускаю ?
Очень просто. Я хочу показать тебе, что твой призыв никуда не годится.
PD>Ну предположим на минуту, именно я их допускаю. Допутим, я программист никуда не годный, к эффективности призваю, а сам эффективно делать не умею.
Не, лучше допустить, что, во-первых, пока ты программу не напишешь, ты точно не узнаешь что эффективно, а что нет. А во-вторых, и это очень важно, оценка эффективности зависит от обстоятельст и очень сложна. Т.е. тот самый новичек, о котором ты заботишься, скорее всего просто не сможет верно оценить эжффективность. И оценит неверно. И может получить менее эффективное решение, чем если бы он ничего оптимизировать не пытался. Примеры этого я встречаю сплошь и рядом.
PD>Но все же пытаюсь делать как лучше, ну а что уж получается — в меру моих способностей и знаний
Так может и не стоит заранее оптимизировать, а, вместо этого, думать о прозрачности кода? Может лучше пройтись профайлером и по факту поправить только узкие места? Оно и проще и решение в итоге качественнее получается.
PD>Опять-таки — не использовал я like. Я там бог знает что закрутил, такого ни в какой теории БД нет, потому как и назвать свою разработку БД я не могу, просто это некая структура файла.
Так ты закрутил или это сканер такие данные предоставляет?
Ладно, давай закончим. В общем, ситуация ясная, мы тут на разных позициях, договориться не удастся, еще десяток аргкментов с одной или другой строны — просто сотрясение воздуха. Отвечу только на технические вопросы.
AVK>Как их определить? Вот ответь мне на простой вопрос — что эффективнее, LinkedList или ArrayList?
Я, увы, в .Net новичок, отвеитить пока не смогу. Вот что эффективнее — массив С++ или список С++ — это, пожалуйста.
AVK>Можно реальный пример? На основании чего ты шрифт будешь подбирать?
А черт его знает. Имени гарнитуры. Глифа. Размера (для растровых) И т.д. Не все ли тебе равно ? И я выбирать буду, и ты будешь, только делать будем по — разному.
AVK>Не, ты написал про каких то гипотетических новичков, которые интероп осилить не могут. А вот чем тебя лично он не устраивает?
Меня — 100% устраивает. Но тогда уж просто признайте, что нельзя эффективно писать в .Net, если вы не знаете досконально WinAPI.
PD>>Эти файлы туда сканер засылает.
AVK>Как? Прямо на диск посредством DMA?
Не знаю. Автоматический сканер, работает круглосуточно. Как он работает — меня не касается, я на это повлиять не могу. Еще раз — это дано. Это исходные данные.
PD>>Опять-таки — не использовал я like. Я там бог знает что закрутил, такого ни в какой теории БД нет, потому как и назвать свою разработку БД я не могу, просто это некая структура файла.
AVK>Так ты закрутил или это сканер такие данные предоставляет?
Это я закрутил. В виде псевдо-БД. А сканер в другой совсем каталог фотографии заносит, и делает это непрерывно. Фотографии — исходные данные, а моя БД — для их обработки.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я, увы, в .Net новичок, отвеитить пока не смогу. Вот что эффективнее — массив С++ или список С++ — это, пожалуйста.
Классно! Пожалуйста, расскажи, что эффективнее — массив С++ или список С++?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я, увы, в .Net новичок, отвеитить пока не смогу. Вот что эффективнее — массив С++ или список С++ — это, пожалуйста. S>Классно! Пожалуйста, расскажи, что эффективнее — массив С++ или список С++?
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Как их определить? Вот ответь мне на простой вопрос — что эффективнее, LinkedList или ArrayList?
PD>Я, увы, в .Net новичок, отвеитить пока не смогу.
.NET тут не при чем. То же самое есть и в Java, к примеру. Что это понятно из названия — список на массивах и связанный список.
AVK>>Можно реальный пример? На основании чего ты шрифт будешь подбирать?
PD>А черт его знает.
Т.е. не знаешь. Так и запишем. Характерный, кстати, пример той самой premature optimization.
PD> Имени гарнитуры. Глифа. Размера (для растровых) И т.д.
А смысл? Зачем это надо?
PD> Не все ли тебе равно?
Нет, не все равно. API должно быть максимально удобно для реального использования, а не для гипотетических проблем. Этим, кстати, и отличаются академические разработки от промышленных.
AVK>>Не, ты написал про каких то гипотетических новичков, которые интероп осилить не могут. А вот чем тебя лично он не устраивает?
PD>Меня — 100% устраивает.
Ну вот и отлично. И спорить тут больше не о чем.
PD> Но тогда уж просто признайте, что нельзя эффективно писать в .Net, если вы не знаете досконально WinAPI.
Зависит от задачи. В некоторых случаях нельзя, в других можно. Ты лучше сам признай, что нельзя эффективно писать в .NET игнорируя базовую идеологию платформы.
AVK>>Как? Прямо на диск посредством DMA?
PD>Не знаю. Автоматический сканер, работает круглосуточно. Как он работает — меня не касается, я на это повлиять не могу. Еще раз — это дано. Это исходные данные.
Исходные данные это то что по проводу приходит. А 100000 файлов на диске в одном каталоге это уже косяки ПО.
AVK>>Так ты закрутил или это сканер такие данные предоставляет?
PD>Это я закрутил. В виде псевдо-БД. А сканер в другой совсем каталог фотографии заносит, и делает это непрерывно. Фотографии — исходные данные, а моя БД — для их обработки.
Т.е. все происходит в реальном времени и ты вполне можешь на лету, пусть не в БД, но хотя бы по каталогам раскидать?
. Ежедневно, ежечасно, и в массовом масштабе.
.
1.1.4 stable rev. 510
