У меня есть страшное подозрение, почему Микрософт так любит сериализацию.
Дело ИМХО в том, что Б.Гейтс, как известно, институт не закончил. Так вот, подозреваю, что его там успели научить работе с последовательными файлами, а до файлов прямого доступа он не добрался. К тому же не все версии тогдашнего Бэйсика умели с ними работать ИМХО.
Дело ИМХО в том, что Б.Гейтс, как известно, институт не закончил...Вот вам и результат. :-)
ты дворкин институт закончил? и каков результат? сколько написано строк кода при твоем личном участии при твоем личном руководстве? сколько человек в мире воспользовалось этим кодом? сколько миллиардов заработано?
Здравствуйте, Nimnul, Вы писали:
N> Меня вот что поражает как легко разработчики идут на жертвы производительности ради собственного удобства.
Меня другое поражает... С каким упорством разработчики борятся за производительность там где это не надо...
[Обличения в демагогии поскипаны]
Ты уж извини, но ты сам начал. Эта дисскуссия твоими оппонентами велась корректно, на примерах, фактах и логических построениях. А когда тебе на твоих же примерах показали что ты не прав, то, вместо того чтобы понять что ты ошибался и что необходимость непоследовательного доступа при сериализации как минимум не так примитивна, как 2х2=4, перешел на личности. А вот это как раз и называется демагогией.
Еще раз извини, но так вести себя в спорах нельзя.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Я обещал дискусию закончить, но решил еще одно замечание сделать. Теперь уже не столько о проблеме, сколько о твоем методе дискутировать.
S>Павел, я не спорю с тем, что при записи задом наперед метод сериализации плохо подходит. Я только не понимаю, почему ты настаиваешь на необходимости писать задом наперед. И уверяешь меня, что необходимость писать задом наперед прямо-таки в каждом проекте с необходимостью присутствует. А вот те, кто придумывал сериализацию для MFC, дотнета и джавы почему-то думают, что необходимость писать задом наперед - экзотика. И меня настораживает как раз то, что ты почему-то отказываешься назвать настоящие причины, по которым надо писать задом наперед
S>А, ну конечно. Как критиковать Билла, так у тебя и время и желание. А как только выяснилось, что и матрицы ты хранишь неэффективно, и про то, что Якоби — самый неудачный алгоритм диагонализации, не в курсе — так сразу время пропало? Ну ладно, освободишься — приходи. Постараемся помочь с выбором правильного алгоритма
(Все выделено мной — PD).
Вообще говоря, когда люди дискутируют, у них на то разные причины бывают. Иногда хочется установить истину — она, как известно, в споре рождается. Иногда хочется свои убеждения (представления, мнения) вынести на суд оппонентов — проверить их, послушать возражения, убедиться, что ты прав, что серьезных возражений нет. И другое бывает.
Но есть еще одна причина. Стремление доказать свое мнение любой ценой. Для политиков это нормальный метод. Они так устроены — коль они из КПРФ, надо доказывать преимущетсва коммунизма, коль из СПС — преимущества капитализма. Если же в дискуссии задается неудобный вопрос — о, тогда есть много способов от него уйти. Например, переключиться на другое (у вас народ голодает — а у вас негров линчуют), действовать на эмоции (так вы что, против народа ?) Подменить предмет спора, заставив собеседника обсуждать, то, что ему невыгодно. Унизить собеседника (странно, что Вы не знаете, что в 19xx году в СССР были XYZ — может , были, может не были, а эффект есть — создано впечатление , что противник плохо осведомлен) И т.д. И т.п. Потому что цель здесь — не истину установить. Цель — побольше голосов на выборах получить. На тех подействовать, которые колеблются, а самостоятельно мыслить не очень умеют. И , в общем-то, я политиков в этом не очень и виню — роль такая.
Но то, что применимо в политике — неприменимо там, где целью дискуссии является все же установление истины.
К сожалению, я вижу, что именно этот стиль дискуссии ты и применяешь. Речь шла о пустяках — стоит ли писать в файл строго последовательно или это необязательно. Тема для изучения на 1 курсе университета. Я привел ряд примеров, когда не стоит. Честно говоря , писал — сам удивлялся — с чего это я вдруг должен доказывать, что 2*2=4.
В ответ с твоей стороны был применен практически весь набор тех методов, о которых я написал. И стремление сменить тему дискуссии (я просто для демонстрации привел пример вывода матрицы на диск в определенном формате — так почему же я не использую при этом архивацию ?) И стремление навести тень на плетень, заставив меня обсуждать бог знает зачем алгоритм Якоби, а для этой цели назвав его самым неудачным (те, кто с выч методами незнаком, вполне могут и поверить ), хотя из твоих замечаний ясно, что ты о диагонализации знаешь столько же, сколько я о религии папуасов. И уход от неприятных вопросов (как в случае с PE-форматом — там, кажется, что-то о сегментах) И стремление унизить собеседника ("Постараемся помочь с выбором правильного алгоритма"). И попытка действовать на подсознание (чего стоит одно навязчивое упоминание "задом наперед" в абзаце выше — хотя совершенно ясно из моего письма, что писать задом наперед я отнюдь не предлагаю, кажется, даже смайлик там поставил. Но употребим эту фразу почаще — а вдруг действительно кто-то решит, что Pavel Dvorkin настолько неграмотный программист, что уверен, будто лучший способ писать в файл — задом наперед, да еще и причины почему-то отказывается назвать — настораживает это, относитесь к его высказываниям с осторожностью. И т.д.
В общем, впечатление такое, что не истина тебя интересует. Твоя цель — выиграть в споре любой ценой. Зачем тебе это нужно — не знаю, мне, собственно, это не важно. Плохо другое — спор с тобой попросту начинает утомлять через несколько итераций. Вместо нормального отстаивания своих позиций там, где они крепки, и сдачи тех, которые защитить невозможно — всевозможные уходы в сторону, словом, весь тот набор приемов, о котором я говорил. Мне попросту скучно с тобой спорить становится — ну не могу же я тратить время на обсуждение совсем к делу не относящихся вопросов, да еще на твои периодические "наезды" (не нужен ли вам алгоритмист, постараемся помочь с выбром правильного алгоритма и т.д.)
А жаль. Потому что в других ситуациях, когда ты говоришь о серьезных вещах и не защищаешь то, что защитить невозможно — тебя интересно слушать. Но начать с тобой это обсуждать — есть риск, что в какой-то мелочи мы не сойдемся. И если это случится — весь набор твоих методов будет обязательно применен, из кожи вон полезешь, только бы доказать свою правоту.
Антон, подумай над тем, что я сказал. Просто подумай. Можешь, конечно , мне письменно возразить, за тобой право последнего выстрела в этой дискуссии , я уже точно не отвечу, но после того, как возразишь (я в этом не сомневаюсь — просто сам подумай. Тихо. Спокойно. Не на публику. Для себя.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>В конечном счете речь идет о сохранении чего-то в файле (я не забыл про всякие memory stream, но опустим их пока что).
Это заблуждение. Сериализация никак не связана с файлом. Сериализация — преобразование в последовательное представление. Где здесь упоминание про файл? Нету. Упс. Не надо додумывать единственное решение к сложной проблеме. PD>А файл (не file Виртовского паскаля, а натуральный файл) есть структура прямого доступа вообще-то. К персистентности у меня никаких возражений нет, но почему эту персистентность надо делать, записывая данные именно последовательно — это я в общем случае не понимаю (в частных случаях вполне могу быть согласен).
Смешно. Вот как раз в частном случае персистентность можно делать на чем-то специфическом. А в общем случае, чем меньше мы требуем от подсистемы персистентности, тем больше ее реализаций нам доступно. PD>Сохранять данные последовательно во многих случаях вполне разумно. В других — ИМХО совершенно неразумно, так как их сохранение по природе своей не есть выкладывание в линию. Иногда лучше сначала зарезервировать в файле некоторое место, просто не записать туда ничего, выложить в файл все остальное, потом вернуться туда и записать пропущенное. К примеру, разреженную матрицу ИМХО именно так и следует записывать — оставить место для количества ненулевых элементов (4 байта), выложить все тройки (row,col,value), по ходу действия подсчитав их количество, потом спозиционироваться на место для этих 4 байтов и записать это количество. Можно, конечно, в 2 прохода сделать, тогда будет именно сериализация, но, простите, зачем ? Во имя принципов ?
А зачем делать вот это туда-сюда? Вместо этого можно придумать маркер конца матрицы (например, -1, который не может быть валидным row).
Если смущает необходимость перевыделять память для матрицы при чтении, то я вообще уже ничего не понимаю: если мы собираемся десериализовывать матрицу в квадратное неразреженное представление, то нам вообще длина не нужна. А если она и в памяти разреженной хранится, то непонятно, почему она не знает свой размер в самом начале сериализации. В общем, в очередной раз я вижу победу оптимизации над здравым смыслом, которую я уже наблюдал в топике про длину строк. И опять же приходит мне на ум проблема преподавания, которая приводит к таким результатам — ты замечательно видишь отдельные деревья, но напрочь отказываешься видеть лес. PD>Лично мне в моей работе пришлось однажды заняться тем, что можно назвать "выкладывание в файл". Но вот сериализацией назвать это язык не поворачивается. Потому что там создавались довольно сложные структуры, частями записывались в файл (хранить в ОП не мог — там десятки и сотни Мб), потом в файле я возвращался назад, заполнял их блоки управления, потом опять назад, заполнял блоки управления более высокого уровня и т.д.
PD>А вообще должен сказать, что никогда никаких проблем с записью в файл у меня не было. Еще в DOS времена как освоил fopen-fwrite-fread-fseek-fclose, так до сих пор и пользуюсь. Ну разве что иногда перехожу на CreateFile etc. И, конечно, файл-мэппинги. Как, кстати, насчет их ? Там ведь, по большому счету, то же выкладывание в файл идет (если надо файл сохранить, конечно), только вот кому захочется при работе файл-мэппингом запретить себе свободно перемещать указатель — я посмотреть бы хотел.
Конечно, во времена ДОС все было прекрасно. А в наше время приходится регулярно работать с объектами, не поддерживающими произвольный доступ. Если ты научил свой объект сериализовываться, то внешний код может воспользоваться этим для сохранения в файл на диске, сохранения в файл на ftp-сервере, пересылке по сети, да еще в сотне контекстов. В том числе есть и очень важное умение: сохранение в поток можно делать рекурсивно. Т.е. если у нас есть набор объектов, каждый из которых умеет сохраняться в поток, то и весь набор автоматически умеет сохраняться в поток. А вот организовать что-то полезное из агрегата "файлоумеющих" объектов не удастся, потому что каждому нужен отдельный файл.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не надо путать два понятия
PD>1. Выкладывание объекта в линию. PD>2. Последовательный механизм реализации выкладывания объекта в линию.
У тебя в очередной раз в голове каша. Нет никакого выкладывания объектов в линию. Есть сериализация — сохранение состояния объекта.
Вот когда ты начнешь мыслить этими терминами, то и проблем с пониманием не будет.
PD>Если поток допускает перемещение в нем (любой файл на диске), он ИМХО должен поддерживать механизм перемещения. А если он поддерживает — то и вопроса нет. То, о чем я писал, говоря о своей задаче — и есть выкладывание в линию (в файл), но механизм этого выкладывания отнюдь не последовательный. И FILE* в этом смысле — тоже поток, хотя его так и не называют.
Тут мы плавно переходим к понятию бастракций и к понятию их иерархий.
Итак вернемся к потокам. Поток является более абстрактным понятием нежели поток/файл с возможностью перемещения в нем. Код написанный в расчете на работу с потоком без проблем может быть применен для записи как в файл, так и какой-нибудь сокет. Обратное не верно.
Реализуя сериализацию разумно рассчитывать на то, что она может быть применена в любых допустимых целях. В том числе и для передачи данных через однонаправленные каналы или записи в простые потоки. Именно поэтому интерфейс сериализации работает с потоком, а не с чем-то более конкретным (вроде файла).
То что в твоей конкретной задаче требуется сохранять состояние в файл — это всего лишь частности твоей задачи. Согласись совершенно бессмысленно менять универсальные механизым под потребности частной задачи если ее можно решить в рамках универсальных механизмов.
PD>И второе. Нет причин, по которым механизм сериализации должен использоваться для каких бы то ни было действий в оперативной памяти, (если не предполагается в дальнейшем передавать сериализованные данные на последовательное устройство). Оперативная память есть RAM (Random access memory) и превращение ее в Sequential access memory (или address space, не важно) ничем не обосновано.
Опять таки. Нет никакой разницы на чем реализован конкретный поток. Ты работаешь с абстракциией! Все! Не нужно пытаться заглянуть внутрь этой абстракции.
Ну, а что до того зачем может потребоваться локальная сериализация... Хорошим примером может служить глубокое копирование графа объектов. Это не простая задача, но если есть готовый механизм сериализации, то можно просто сериализовать состояние графа в поток, а потом десериализовать его получив копию графа объектов. Если сереализация сделана достаточно эффективно, то все ОК. В ином случае придется создать кучу специализированного кода.
ЗЫ
Вообще данный вопрс показывает то что большинство твоих проблем происходят из-за того, что ты не умешь мыслить абстракциями. Ты все время пыташся влезть в реализацию и сделать далеко идущие выводы. Это будет всегда мешать тебе решать действительно сложные задачи, так как без введения абстракции и оперирования ими сложность будет непомерно высока.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
P>ты дворкин институт закончил? и каков результат? сколько написано строк кода при твоем личном участии при твоем личном руководстве? сколько человек в мире воспользовалось этим кодом? сколько миллиардов заработано?
Могу ответить, конечно, но тон вопроса таков, что отвечать не буду.
Хамить не надо не только по телефону (М. Булгаков), но и в Интернете тоже.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Откровенно говоря, мне жаль, что я начал опять с тобой дискуссии. Не умеешь ты нормально дискутировать Так что этот ответ опять будет последним.
Ну, извини. Что вижу, то и говрю. Обижать тебя ни малейшего желания не было.
PD>Serialization Преобразование в последовательную форму
PD>Это мне словарь выдал (Socrat 4.1)
Словарь плохой (пользуйся Лингвой), но в пренципе на этот раз перебод более менее корректный. Главное правильно его понять.
PD>Не любое сохранение состояния объекта есть преобразование в последовательную форму. Я могу, к примеру (вольная фантазия), сохранить массив в бинарное дерево, если мне такое вдруг захочется. Надеюсь, ты не будешь возражать, что из бинарного дерева я смогу восстановить массив?
Вообще-то буду, так как массив нельзя без потери информации преобрзовать в дерево (если только вырожденное). Но это к делу не отностися.
PD> Означает ли это, что преобразование массива в бинарное дерево есть сериализация ? Означает ли это, что любая запись объекта в базу данных (безусловно сохранение состояния объекта) есть сериализация ?. Так ведь под сериализацию можно все, что угодно подвести.
Еще разок. Сериализация есть сохранение состояния объекта. Согласен, ты правильно уточнил, что в последовательную форму. Под последовательной формой тут понимается некая простая структура данных с которой можно легко манипулировать. Естественно, что такой структурой является плоский массив байтов или поток.
Еще раз хочу заострить внимание. Ключевое слово здесь сохранение состояния.
PD>Это во-первых. Во-вторых, речь шла не о том, выкладывать или нет в линию,
"Выкладывание объекта в ряд" — это или пример извращеной терминалогии, или не понимания смысла процесса. Так что не нужно вообще так говорить.
PD> а , подчеркиваю, о механизме этой операции. И механизм этот в общем случае не является последовательным.
Под "механизмом" ты понимашь алгоритм? Если да, то еще раз отсылаю к понятию абстракции. То как производится сериализация совершенно не важно. Важен результат. А он заключается в том, что сложно структурированный граф объектов превращается в последовательность байт.
PD> И не надо аргументировать это тем, что дескать, общие принципы должны соблюдаться независимо от типа destination. Это совсем не обязательно.
Естественно! Вообще многое не обязательно. Например, не обязательно выходить на улицу в одежде или при размышлениях пользоваться логикой. Нет сомнений, что пользоваться абстракциями не обязательно. Но как показывет практика отказ от нее приводит к печальным последствиям. Возможно на маленьких примерах это не сильно заметно. Но в масштабах большого приложения, а темболее несколькоих наплевательство на абстракцию обходится очень дорого.
Именно по этому грамотные люди очень серьезно подходят к выбору абстрации и стараются соблюдать ее каноны. Структурное программирование и ООП собственно и бил созданы для этого.
PD> Если у меня никакая передача по сокету не предполагается, а предполагается только запись в дисковый файл, то я совсем не обязан писать код последовательного выкладывания, а вправе писать его как мне удобно.
Ты не обязан вообще ничего. Но если ты разумный программист, то не будешь создавать проблемы себе и другим.
Разумный программист отделит задачу сериализации от задачи записи в файл. Не разумный по капризу, недомыслию или в погоне за очередной оптимизацией может наплевать на абстракции и сделать несколько почти одинаковых решений отличающихся мелочами вроде способа записи.
PD>Впрочем, если ты готов признать, что сохранение сотояния объета не означает обязательно последовательное выкладывание его полей в поток, а может быть реализовано так, как мне удобнее — я готов о терминах не спорить и согласиться.
Сериализация вообще не является последовательным выкладыванием полей в поток (в прочем как и объетов). Сериализация — это преобразование состояния объекта в последовательную форму. То как это делается уже вторично. Ты можещь использовать разнообразные промежуточные структуры, сохранять только часть полей или даже некоторую функцию от состояния объекта по которой потом можно будет востановить это состояние. Это уже все детали. Главное, что в итоге ты должен получить массив байтов/поток в ктором находится состояние графа объектов.
VD>>Вообще данный вопрс показывает то что большинство твоих проблем происходят из-за того, что ты не умешь мыслить абстракциями.
PD>Меня принципиально не интересуют абстракции до тех пор, пока мне не ясна их имплементация.
Вот это-то и плохо! Реализация не должна вообще рассматриваться в контесте выбора абстракции. Ведь одну и туже абстракцию можно реализовать разными способами.
PD> Именно благодаря тому, что некоторые программисты предпочитают мыслить абстракциями, не задумываясь о том, как будет все это реализовано, мы и имеем то плачевное состояние с производительностью, о котором я писал полгода назад. Повторяться на эту тему я не буду.
Гы. Ты уже повторился. И никто за язык тебя не тянул.
Я тебе так скажу. Ты выдумал себе проблемы или создал их себе сам. У меня, например, особых проблем с производительностью нет. Все мои программы достаточно быстры. Точнее их производительность достаточна для решаемых задач.
Кстати, если уж говорить о производительности, то хочу заметить, что чень смешно наблюдать как ты рассуждашь тут о реализации сериализации и при этом в соседнем форуме видно, что ты изучаешь и используешь НКибирнэйт. Воможно ты не знашь... дело в том, что НКибирнэйт — это O/R Mapper. А O/R Maping — это саое не эффективное средство работы с данными хранящимися в БД. Удобная, высокоуровневая, но принципиально неэффективная. Обычно решения основанные на O/R Maping-е приблизительно в 10 раз менее эффективны чем аналогичные исползующие прямую работу с БД. Заметь, я не отговриваю тебя от использовани НКибирнэйта. Я просто замечаю, что твоя борьба за производительность очень странно выглядит.
>>Ты все время пыташся влезть в реализацию и сделать далеко идущие выводы. Это будет всегда мешать тебе решать действительно сложные задачи, так как без введения абстракции и оперирования ими сложность будет непомерно высока.
PD>Нет. Это лишь дает мне возможность искать правильное решение — и с точки зрения высокого уровня (абстракций) и с точки зрения низкого уровня (реализации).
Небывает уровеня реализации. Быают разные реализации абстракций и (иногда) алгоритмические ограничения абстракций. Например, связанный список накладывает принципиальные ограничения на скорость последовательного доступа. Вот только сериализация то тут причем?
PD> Мыслить абстракциями я вполне могу, но найдя решение на уровне абстракций, я тут же задам себе вопрос — а как это будет на уровне реализации ?
К сожалению, лично я вижу что ты сваливашь в одну кучу абстракцию и реализации, а потом пыташся в этом всем разобраться.
PD> И если абстракция хороша, а реализовано эффективно быть не может в данной задаче — на помойку такую абстракцию, поищем другое решение. По крайней мере для реальных программ и реальных машин. А абстракции, которые не имеют эффективной реализации в данной ситуации я оставляю тем, кто иначе писать не умеет.
В том-то и дело, что вопрсы оценки характиристик абстрации не связаны с вопросами ее реализации. Одна и та же обстракция может быть реализована более или менее эффективно. А оценить пригодность абстракции можно ничего не зная о ее конкретной реализации.
Более того, ты делашь массу предположений основное количество которых не подкреплено никакими фактами. Ты думшь, что А медленно, а Б быстро. Но на самом деле все может оказаться совсем не так. Как в том самом случае с чтением файлов по байтам. Поробуй как-нить на досуге прочитать побайтно файл в дотнете через его абстракции.
В общем, я не понимаю, как можно не понимать стольк простых вещей.
Ну, нет никаких проблем для того, чтобы эффективно сериализовать все что угодно в поток байтов. Ну, нет! Ты можешь банально сделать это в помяти и вернуть требуемый интерфейс воспользовавшись каким-нибудь MemoryStream. Так зачем же жертвовать абстракцией и писать какие-то частные клагоритмы которые можно использовать только в отдельных случаях?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>И зачем это люди архиваторы используют ? Хранили бы файлы как есть. Современной системе это до лампочки!
Вот кстати если использовать архиватор, то он сам выкинет все эти нули. А знаешь, в чем прелесть? В том, что зип сожмет и матрицу из всех единиц. А твой алгоритм разбарабанит ее вдвое. При этом для скармливания ее зипу все равно придется сначала выделить буфер размером в 8mb, потому что тебе очень хочется вернуться в начало.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Я тоже. И что?
PD>Не знаю. Спроси VladD2. Он же начал меня в непонимании идей ООП обвинять.
Он обвинял тебя в неумении ими пользоваться.
AVK>>То, что ты описал называется оптимизацией. Которая почти всегда ухудшает структуру программы. Но оптимизации делают обычно, когда точно известны узкие места. Делать ее заранее и везде — прямой путь к убийству мало мальски крупного проекта. Именно об этом и пытается тебе сказать Влад.
PD>Я уже на эту тему выступал осенью. Не хочу возвращаться к ней.
То есть признаешь, что приводить подобное в качестве правильного примера в проектировании программ не стоит?
AVK>>1) Предлагая одновременно с абстракциями думать о реализации, ты увеличиваешь количество сущностей на одном уровне.
PD>На разных уровнях. Я об этом писал в письме к Владу — переключение между уровнями.
Чудес не бывает. Человек штука однозадачная.
PD>[Остальная часть этого замечания skipped в связи с этим возражением.]
Класс! Это нифига не замечание было, это был вопрос. Повторю еще раз в краткой форме — как ты предлагаешь бороться с увеличением количества сущностей ввиду того что нужно учитывать аспекты реализации? Или ты считаешь что проектирование с учетом реализации и без такового на одной и той же задаче равноценно по сложности?
>>Теперь собственно вопрос — в какой момент нам следует прекратить думать о реализации нижележащих абстракций?
PD>На том уровне, на котором изменение в реализации перестает влиять на свойства программы (быстродействие, память и т.д.)
Как определить? Где гарантия что, к примеру, твои сики туда и обратно не вступят в конфликт с файловым кешем ОС, и в результате ты получишь более медленное решение вместо ожидаемого более быстрого? Мой опыт доказывает, что зачастую узкие места обнаруживаются там, где их никто предсказать не смог бы. Так что такой способ не годится.
PD> Или когда мы попадаем на уровень, который нам неподвластен. PD> Как только один из этих уровней достигнут — стоп. Дальше думать не о чем — думай не думай, а ничего не изменится.
Ну и что что неподвластен? Вот кеш у процессора нам тоже неподвластен, однако мы же можем его учитывать?
Итого: на оба заданных вопроса я ответа не получил. Исходя из этого задам другие вопросы — насколько сложнее проектирование при постоянном учете реализаций? Во сколько ты оцениваешь стоимость ошибок, вызванных неправильной оценкой эффективности реализации на реальных источниках данных? Насколько оправдано сужение универсальности алгоритма в угоду его производительности? Всегда ли стоит предпочесть более эффективное решение более универсальному? Где золотая середина между скоростью разработки и эффективностью полученного решения? Насколько сильно отразится твой подход на восможности реиспользования и модификации полученного решения?
>>Почему я, при создании сериализации, должен думать о файле, но не должен думать о кластерной структуре ФС?
PD>Потому что ты не выбираешь ФС.
Но я выбираю алгоритмы работы с ней. Например на FAT поиск файла это очень дорого, а на NTFS есть индексы и поиск значительно дешевле. Какое грамотное решение ты видишь в подобной ситуации? Наплевать на то, что в случае NTFS мы получаем оверхед и городить свои индексы? Или сделать решение, тормозящее на FAT?
>>Или должен. Тогда когда не должен? Об абстрактной модели контроллера IDE должен?
PD>Не должен. Ни к к какому улучшению это не приведет.
Я бы не был столь уверен. Современные винты имеют очень непростое firmware, а каждый процент производительности дисковой подсистемы сегодня очень ценен. Как считаешь — стоит учитывать особенности firmware, или сделать универсальное решение, неоптимальное в каждом конкретном случае? Из той же серии — стоит учитывать кеш процессора, если размер и алгоритмы работы на сегодня довольно существенно разнятся для разных процессоров?
PD> А если залача такова, что приведет и можно выбирать — должен.
А как определить что задача такова? И в какой момент это можно сделать? Я лично знаю только один такой способ — произвести замеры на реальном решении или хотя бы прототипе. Но для этого надо архитектуру уже разработать! Замкнутый круг?
PD>(В скобках. А это не демагогия ?
Нет.
PD> При чем тут контроллер ?
Один из уровней абстракции. Если еще не забыл, я пытаюсь узнать критерии глубины погружения от собственных абстракций в чужие.
PD>Чем мне помогут мысли о контроллере, если я никак на его выбор повлиять не могу ? При чем тут ФС, если я ее тоже выбирать не могу! )
Это, кстати, не факт. Я видел и списки рекомендованных контроллеров, и обязательное требование (впрочем как и просто рекомендации) использования NTFS. Так что все возможно, вопрос лишь в цене.
AVK>>Я тебя умоляю — не стоит делать далеко идущие выводы из аналогий. Строительство это далеко не то же самое, что создание программ и тому есть масса причин.
PD>Все аналогии хромают. Эта тоже.
Ну вот тогда и не делай из них выводы. Единственное использование аналогий в споре, не являющееся демагогией, это применение их в качестве иллистраций каких то высказываний. Ты же сделал вывод, опираясь только на аналогию (здание рухнет, если не рассчитать прочность каждого кирпича -> программа рухнет, если не рассчитать прочность каждого кусочка кода).
PD> Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
Где? Не вижу.
AVK>>Это нормально. Называется рефакторинг. Ничего страшного в нем нет.
PD>Вполне согласен. Я же об этом говорил — откажусь от нее (кстати, если уж на то пошло, в реальной работе я сначала именно ее и попробую, зачем мне лишние сложности ?) и задействую иное.
А зачем учитывать то, что еще не определено? При начале проектирования как правило известно очень мало, причем часть информации принципиально неопределена? Почему, вместо того чтобы напрягать интуицию, не выбрать простейшее решение и построить код таким образом, чтобы его легко было модифицировать?
Небольшой пример — как то пришлось воспользоваться библиотекой редактора графов — NetronGraphLib. Библиотека весьма куцая по функционалу, с ошибками и не очень хорошей реализацией (автор явно плохо знал C# и .NET). Но есть у нее неоспоримое преимущество — она написана так, что ее легко модифицировать. В результате я за сравнительно небольшое время привел ее в соответствие со своими требованиями и ни разу у меня не возникло желания написать все с нуля.
Другой пример — в .NET Framework 1.х отсутствуют нормальные тулбары и менюхи. Вначале в янусе использовали крутую MagikLibrary. Но глюков было столько, что пришлось от нее избавится. Потом была не менее крутая UserControlLibrary (сейчас она как то по другому называется), от нее тоже пришлось избавиться ввиду неудобоваримости. В итоге вплоть до появления 2 версии фреймворка в янусе использовалась простенькая, без супер реализации, зато с качественной моделью (читай с грамотно спроектированными абстракциями) CommandBars.
PD> А другие пытаются ее изо всех сил все же запихнуть, доказывая, что она годится там, где она не годится. В этом все различие.
Я наверное что то не понимаю, но тебе тут о другом говорят. Не о том что надо что то впихнутьт, а о том что абстракции надо делать максимально простыми, не корежа их в угоду своим догадкам о проблемах реализации.
PD>Я — знаю. Не всегда и не везде. Могу ошибиться, с кем не бывает.
Можешь и еще как. Этот топик (да и не только он) — прекрасная тому иллюстрация. Нужно только понять, что это не ты виноват, что частенько ошибаешься и не формат форума тому виной. Я в своей работе регулярно наталкиваюсь на то что, казалось бы, самые очевидные предположения оказываются неверны.
AVK>>Это мелочи. Там проблемы логического плана. Впрочем, попроси об этом рассказать Синклера, у него хорошо получается.
PD>Да я в общем-то как внутри NHibernate устроен, и так разобрался — в небольшой части, конечно, которая меня интересовала. Потрассировал код, посмотрел. Неплохо самодокументировано — понять, что делается, довольно легко.
А как насчет эффективности?
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
> Есть хорошая статья VladD2 на эту тему: Сериализация в .NET. Выпрямляем своими руками
потому что статья если внимательно присмотреться на самом деле написана о частном случае реализации самодельного сериализатора для датасета. причем реализация практически ничего не поддерживает (ни констрайны ни индексы ни релейшны). утверждение что эти фичи не используются в большинстве проектов — детское. проекты которые используют датасеты без этого вопервых врядли можно назвать проектом вовторых таким "проектам" эффективная сериализация не нужна заведомо.
таким образом эта статья не имеет никакого практического смысла. теоретического смысла она то же не имеет т.к. автор не предложил ничего нового для сериализации больших массивов принципиально.
любой наверное догадается что если передача данных по сети съедает непомерное количество полосы то надо что то делать. например передать только те данные которые нужны а излишки опустить. если бюджет позволяет это переписывать самому.
автор приходит к выводу что датасет — большой и сложный объект физически. передача большого объкта по сети не должна занимать много места. предложенная альтернатива — передача объекта имеющего отдаленное сходство с датасетом. для меня это напоминает спор с женщиной-сотрудником: -ты опоздала на 30 мин на работу. -у нас закончилось кофе. — ты покупала кофе? -нет.
поэтому фраза "Есть хорошая статья" и так же название "Выпрямляем своими руками" НЕКОРРЕКТНЫ. У неосведомленных читателей складывается устойчивое впечатление что 1. статью надо использовать как библию 2. на практике средний программист может написать реализацию сериализатора лучше чем МС.
оба положения неверны.
я привел ссылку которая объясняет как передать датасет более эффективным способом если кому нужно. более того если нужны данные в чистом виде — делай запрос в сиквел без датасета.
это и есть практическое решение.
я с удовольствием почитаю любую статью которая дает — либо интересный _практический_ результат при _адекватных_ затратах либо описывает _интересную_ подход/технику в производстве качественных продуктов.
у меня нет никаких сомнений в умственном развитии автора. просто эта статья содержит минимум полезной информации и с учетом напыщенности названия и с учетом что ее теперь распространяют как "хорошая" я позволил себе этот пост, т.к. она искажает действительность без особой нужды.
я рад что есть люди которые пытаются найти ответы на все вопросы. я рад что есть Влад2. я не рад только тому что он тратит время на пустое. и не рад тому что глупые статьи будут висеть в инете годами. надо быть более отвественным к тому что публикуешь. надо немного самокритики добавить. как известно что написано на клавиатуре то не вырубишь молотком.
то что ты расказал весело , XML увеличивает размер файла на 20%-30% а то и больше, причем все эти теги — это мусор, опятьже все это нужно для удобства программинга, также как и ремоуинг, также как и сериализация, и IClonable и иже сними. Меня вот что поражает как легко разработчики идут на жертвы производительности ради собственного удобства.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>О! Вот с этим готов полностью согласиться.
PD>И, конечно, дело не в управляемых средах или именно Remote интерфейсах, а тем более в XML-формате. Дело в том, что в этих задачах предполагается именно последовательная передача данных. Либо устройство иное не поддерживает, либо это по иным причинам требуется. И тогда, конечно, именно сериализацию как алгортим надо использовать.
PD>Но зачем тогда адепты ее упорно пытаются ее загнать туда, где она совсем не нужна ?
Это становится проблемой адептов. Вообще к каждой технологии нужна методология ее применения. Как, где и почему. К сожалению большая часть тех, кого ты назвал "адептами" предпочитают об этом забывать и пытаются пихать ее во все дыры до куда дотянутся. Слабый народ, ведется на рекламу.
PD>>Но зачем тогда адепты ее упорно пытаются ее загнать туда, где она совсем не нужна ?
_>Это становится проблемой адептов. Вообще к каждой технологии нужна методология ее применения. Как, где и почему. К сожалению большая часть тех, кого ты назвал "адептами" предпочитают об этом забывать и пытаются пихать ее во все дыры до куда дотянутся. Слабый народ, ведется на рекламу.
Со всем согласен, кроме последнего. Не в рекламе тут дело. Боюсь, все серьезнее. Формируется некое мировоззрение, в котором нормой явялется не думать о реализации или по крайней мере не считать это главным. Отчасти это понятно — мы пришли к модульному, компонентному программированию, т.е построению не из кирпичей, а из крупных блоков. Беда в том. что эти блоки ставят и там где надо, и там где не надо, а о том, как они устроены (как выглядят) — в последнюю очередь думают.
Храм Василия Блаженного дай им спроектировать — нечто в стиле кубизм получится. Крест наверху обязательно будет (функциональность надо обеспечить!), фасад будет на месте, внутри и алтарь, и царские ворота, и т.д.(а то заказчик не примет), А посмотришь на него — не храм Василия Блаженного, а Кремлевский Дворец съездов . А ведь и из крупных блоков храм построить можно было бы. Только блоки другие брать надо... Не всегда в виде параллелепипеда, иногда закругленные, иногда в виде луковицы . Делать их, конечно, придется, не все домостроительные комбинаты такие выпускают. Времени уйдет больше, точно. Зато будет храм...
PD>с выпадом в мой адрес в самом начале
PD>это не вызвало с твоей стороны (как модератора) никаких замечаний, а поэтому заставило меня ответить.
PD>Если ты считаешь, что высказывание "у тебя в голове каша " есть корректное ведение дискуссии — у тебя очень гибкие принципы.
Демагогия detected: — в качестве оправданий собственного наезда на Синклера используется поведение Влада.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А я и не создавал. Код, который я писал, вполне успешно работает на сотнях компьютеров, и до сих пор никто не жаловался.
Умение писать работоспособный код — это вопрос минимального профессионального соответствия. Та самая планка, ниже которой стоит слово "уволить немедленно". Настоящего квалифицированного программиста отличает умение писать не только работоспособный, но и легко читаемый, поддерживаемый, расширяемый код. Поэтому не надо рассказывать нам, что твои программы работают. Лучше расскажи, какое количество профессиональных программистов занимается/занималось поддержкой твоего кода. Неплохо бы также узнать их мнение о твоем коде.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В конечном счете речь идет о сохранении чего-то в файле (я не забыл про всякие memory stream, но опустим их пока что). А файл (не file Виртовского паскаля, а натуральный файл) есть структура прямого доступа вообще-то. К персистентности у меня никаких возражений нет, но почему эту персистентность надо делать, записывая данные именно последовательно — это я в общем случае не понимаю (в частных случаях вполне могу быть согласен).
Это элементарно Ватсон!
1. Файл есть еденица хранения данных. Когда речь идет о записи в файл, то речь идет о интфейсе файловой системы.
2. Сериализация нужна не для записи в файл, а для представления состояний объекта или графа объектов в виде пригодном для хранения и передачи.
3. Есть много случаев когда данные удобно передавать/хранить в последовательной форме. Например, при передаче их по сети.
Отсюда люди ввели абстракцию потоков (streams) и их классификацию от самых приметивных последовательных, до специализированных поддерживющих перемещение по содержимому.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
>>Дело ИМХО в том, что Б.Гейтс, как известно, институт не закончил. Так вот, подозреваю, что его там успели научить работе с последовательными файлами, а до файлов прямого доступа он не добрался.
Не-е. Все гораздо проще. БГ научить работе с файлами прямого доступа можно в 6 секунд. А вот научить этому прожженого образованца с тремя высшими задача вовсе нетривиальная и сравнимая по тяжеловесности с реализацией сериализации средствами WinAPI (зато летать будет...).
>>>>Похоже, уверждение страдает некоторой расплывчатостью... То есть, если я выполняю в приложении серьезные ресурсоемкие операции, то сериализовать конфиг файл с настройками уже нельзя?
>>Мне бы не составило труда занести настройки в ini файл и работать с ним посредством Systm.IO И вобще зачем ты преувеличиваешь, речь идет о ресурсоемкой задаче а не программе целиком, ведь уже говорили выще что сериализация работает на два порядка медленнее чем System.IO
Обидно, что XML проездили уши до такой степени, что кроме XML больше ничего уже слышать и не хотят. Дело дошло до маразма месяца два тому назад, когда меня попросили вести лог загруженности процессора в ... XML файл! При частоте опроса счетчика 500 мс загрузка CPU процессом логгера составляла 50%... No comments. Насилу удалось отговорить
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Ну и не надо. Вполне согласен. А вот надо ли при записи в файл использовать сериализацию ? Т.е преобразование в последовательное представление. Или же можно записать в файл без преобразования в последовательное ? В это и вопрос.
Конечно же нельзя. Ибо любой файл после того, как он закрыт — штука сугубо последовательная. Наличие возможности быстро переместиться в любое место этой ленты особого значения не имеет, кроме случаев, когда нужно прочитать только часть информации. А об этом пока речь не шла. PD>Не понял, зачем мне какая-то -1 здесь вообще нужна.
Ничего. Сейчас объясню. S>>Если смущает необходимость перевыделять память для матрицы при чтении PD>Не понял, зачем мне вообще при выводе матрицы в файл что-либо перевыделять. Эта задача решается на O(1) по памяти.
Ключевое слово выделено жырным.
PD>Sinclair, разберись как следует , о чем я говорил.
Ок, но от тебя ожидаю того же. PD>При чем тут размер матрицы ? Речь идет о выводе ее на диск. Исходная матрица разреженная. Размер ее прекрасно известен. Сколько там ненулевых элементов — неизвестно. Надо вывести матрицу в простейшем формате — сначала число ненулевых элементов, затем тройки (i,j, value).
ЗАЧЕМ выводить сначала количество ненулевых элементов? Придумали себе геморрой, а потом с ним мужественно боремся? PD>Вот и выведи. Условия ... Все. Можешь сделать это с сериализацией — давай сюда код.
Вывожу. По буквам:
for(int i=0, i<HSize; i++)
for(int j=0; j<VSize; j++)
if (matrix[i, j] != 0)
stream << i << j << matrix[i, j];
stream<<-1; // вывели маркер конца матрицы.
Вот чтение этой матрицы обратно:
int i, j;
stream >> i;
while(i >= 0)
{
stream >> j >> matrix[i, j] >> i;
}
Вот и всех делов. Здорово, правда? Никакой лишней памяти, никакого лишнего времени, и никакого требования поддерживать произвольный доступ.
PD>А если объект не поддерживает произвольный доступ, то все мои возражения автоматом снимаются. Потому как кроме как о файле, я ничего и не утверждал. А он поддерживает.
Еще раз: вменяемые люди стаарются применять наиболее доступные технологии. Произвольный доступ используется там, где без него нельзя обойтись. Например, в СУБД — там используется страничная организация файла, позволяющая не только читать, но и писать его по частям без нарушения внутренней целостности. Но СУБД и не собираются работать с данными по HTTP. PD>Это все прекрасно и чудесно, вот только в данной конкретной задаче, допустим, все это не нужно. Не нужно и все. Не требуется. Все равно будем сериализовать ?
Что не требуется? Компаунд-объекты? Сегодня не требуется, а завтра потребуется. Все, твоя матрица уехала на помойку, а ты икаешь, т.к. тебя вспоминает недобрым словом тот, кто вынужден переписывать твой код, потому что начальство захотело сделать веб-сервис для матричных операций, а твоя матрица при попытке отдать ее по сети кидает invalid operation exception.
PD>Это что-то новое ? Ты хочешь сказать, что я не смогу таким способом записать 2 объета в один файл. Ну что же, возьми мой пример и запиши 2 матрицы в один файл. Совершенно элементарно делается. Или еще-что записать. Никаких проблем не будет. Делал , и не раз.
Это означает, что на самом деле представление все же сериализованное — ведь матрицы лежат друг за другом. Никакого преимущества твой способ в итоге не дает, зато не умеет передаваться по сети.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не пойдет. Если ты его запишешь в конец, как ты отличишь его от очередной тройки ? Файл-то в действительности будет двоичный, это я просто в текстовом виде привел для наглядности. И я вовсе не обещаю, что после этой матрицы там не будет других данных.
Пойдет. Ты опять, как в случае со строками, придумал себе геморрой, и борешься с ним путем fseek. PD>Можно, конечно, после матрицы всех троек -1 записать как признак конца. Но и это некорректно — а если нумерация строк матрицы не с нуля, а произвольная ?
Если нумерация строк произвольная (что имеет весьма слабый смысл), то достаточно в заголовке записать эти данные вместе с размерностью матрицы. Если смещения заранее известны, то даже этого не требуется. Я тебе заранее могу сказать, что вариант с маркером конца матрицы будет работать как минимум не хуже варианта с префиксом длины, что бы ты ни придумал. Потому, что математика так устроена. PD>А если я структуру вывода усложню ? Она. кстати, там совсем неэффективная, я только для примера привел ее. Лучше хранить не тройки, а PD>число ненулевых строк PD>для каждой ненулевой строки (т.е имеющей хоть один ненулевой элемент) PD> ее номер PD> число ненулевых элементов PD> col, value для каждого элемента PD>У меня в коде мало что изменится. А ты что придумаешь ?
я точно так же стану использовать -1 в качестве маркера конца списка ячеек/строк. И размер данных будет таким же, как у тебя. Только fseek не будет нужен. PD>Но главное не в этом. Придумать во многих случаях можно однопроходной алгоритм. Вопрос серьезнее — зачем придумывать странные структуры данных, когда есть простое и элегантное решение, и единственно, что оно требует — fseek ?
Затем, что оно не элегантное. "Зачем многие женщины занимаются получением профессии и прочими странными вещами, когда есть простое и элегантное решение, и единственное, что оно требует — мужа-миллионера?"
Элегантность — в том, чтобы решение можно было повторно использовать большим количеством способов.
Вот давай теперь я тебе задам задачку: та же матрица, вот только нужно компрессировать ее данные при помощи Gzip. Требования те же: никакой дополнительной памяти, писать все в один проход. Мой код не изменится вообще — я просто отдам сериализатору в качестве таргета GzipStream. И пока ты будешь изобретать свои методы сжатия для каждого случая, я порву твои матрицы на мелкие тряпки. А ты что придумаешь?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Произвольный доступ используется там, где без него нельзя обойтись.
Глупо спорить с этим
Только изначально дискуссия велась о сериализации.
Потом ты ехидно заявил, что BG недоучка, не знает о прямом доступе
и потому везде пихает сериализацию.
В общем с самого начала спор шел на тему
"микроскоп — фигня, потому что с ним орехи колоть неэффективно".
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Если ты не втечал, то это не аргумент. Другие встречали.
Ну и где эти другие? Павел, ты до сих пор не можешь привести примера, кроме вымышленной матрицы со средними значениями, которую еще и читать надо по частям. PD>Я , к примеру, в своей жизни ни разу не встречался с необходимостью посылать что-то в COM-port. Ну не программироваля вывод в COM, вот и все. Дает мне это основания утверждать, что это вообще никогда не требуется ?
Это дает тебе основания спорить с теми, кто заявляет что в среднем задача записи в ком-порт встречается чаще всех остальных задач. А ты именно и утверждаешь, что сохранение объектов всенепременно требует fseek, и совершенно непонятно, как это мы убогие по десять лет без fseek данные сериализуем.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Позволю напомнить тебе, что разреженная матрица была приведена мной не как самостоятельный пример, а как пример того, что при именно ее записи и именно в таком виде метод последовательной записи плохо годится. Если же мне реально понадобится хранить разреженную матрицу — буду действовать в зависимости от задачи.
Павел, я не спорю с тем, что при записи задом наперед метод сериализации плохо подходит. Я только не понимаю, почему ты настаиваешь на необходимости писать задом наперед. И уверяешь меня, что необходимость писать задом наперед прямо-таки в каждом проекте с необходимостью присутствует. А вот те, кто придумывал сериализацию для MFC, дотнета и джавы почему-то думают, что необходимость писать задом наперед — экзотика. И меня настораживает как раз то, что ты почему-то отказываешься назвать настоящие причины, по которым надо писать задом наперед.
PD>Еще раз — не уходи в сторону. Я привел вывод разреженной матрицы как пример для демонстрации, когда сериализация не работает. И только. Я не имел цели рассматривать все способы хранения разреженных матриц и сравнивать их..
Я как раз не ухожу. Я искренне пытаюсь понять, откуда появилось требование писать задом наперед. Может, и правда это такая частая необходимость? Сначала ты очень уверенно писал про какие-то сложные структуры, которые сплошь и рядом не могут быть сохранены в последовательный поток. Но привести ни одного примера почему-то не можешь. Значит, все-таки редко встречаются такие задачи?
А то, что при определенном способе что-то не будет подходить, это ежу понятно. Я могу тебе еще с десяток способов придумать, которые требуют от хранилища не только fseek, но и расширенных атрибутов и дополнительных стримов. Надо? И тоже буду аргументировать тем, что у меня в требованиях стояла winNT, а значит NTFS. А тебя с твоим fseek буду критиковать за неуместное всовывание дурацких прыжков взад там, где можно было просто записать в extended attributes. Надо? Или мы все-таки будем о задачах говорить, а не о сомнительных решениях?
S>>В общем, Павел, результат примерно такой: сейчас не рулят ни догмы, ни интуиция. Рулит умение применять готовые алгоритмы для построения своего решения. И ключом к успеху служит хорошее понимание границ применимости этих алгоритмов.
PD>Результат таков — ты пытаешься переключиться на совсем другую тему. Ее у меня ни времени, ни желания обсуждать нет.
А, ну конечно. Как критиковать Билла, так у тебя и время и желание. А как только выяснилось, что и матрицы ты хранишь неэффективно, и про то, что Якоби — самый неудачный алгоритм диагонализации, не в курсе — так сразу время пропало? Ну ладно, освободишься — приходи. Постараемся помочь с выбором правильного алгоритма
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>Ты уж извини, но ты сам начал. Эта дисскуссия твоими оппонентами велась корректно, на примерах, фактах и логических построениях. А когда тебе на твоих же примерах показали что ты не прав, то, вместо того чтобы понять что ты ошибался и что необходимость непоследовательного доступа при сериализации как минимум не так примитивна, как 2х2=4, перешел на личности. А вот это как раз и называется демагогией.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Со всем согласен, кроме последнего. Не в рекламе тут дело. Боюсь, все серьезнее. Формируется некое мировоззрение, в котором нормой явялется не думать о реализации или по крайней мере не считать это главным. Отчасти это понятно — мы пришли к модульному, компонентному программированию, т.е построению не из кирпичей, а из крупных блоков. Беда в том. что эти блоки ставят и там где надо, и там где не надо, а о том, как они устроены (как выглядят) — в последнюю очередь думают.
Ничего ты не понял из того что тебе тут говорили.
Люди с которыми ты спорил думают от реализации. Вот только они используют совершенно иные принципы при проектировании программ.
Причем проводить аналогии вобще и со строительством в частности не корректно. Однако я тебе таки приведу одну аналогию.
Написании программ гораздо больше похоже на создание проекта дома чем на строительство дома. Дом потом построит компилятор и ему всеравно что строить главное что у него есть план строительства, а вот править уже готовый бинарник очень тяжело также как и что-то перестроить в уже построеном доме.
Причем когда проектируют дом сначала делают эскиз: внешний вид, расположение окон, лесниц, лифтов... На этом этапе вобще не думают о каких бы то нибыло инженерных деталях. Далие определяются с технологией строительства ибо скажем кирпичный дом и дом на основе монолитного железобетонного каркаса строят совершенно по разному. Далие начинают рассчитывать где и какой толщины поставить несущие стены/колонны, сколько и какого утеплителя использовать... на этом этапе могут вносится коррективы (рефакторинг) в проект ибо что-то не учли или заказчик захотел что-то еще. Далие когда проект готов все еще раз проверяют(тестирование).
И только потом отдают строителям.(компилятору)
Нам с одной стороны проще ибо строительство программы ничего не стоит и мы можем посмотреть что получилось, а с другой стороны труднее ибо сложность подавляющего числа программ на порядки превосходит сложность любого здания.
Так вот народу не понравилось то что ты еще во время рисования карандашом на бумаге концепт арта внешнего вида дома пытаешься просчитать нагрузку на каждую несущею коллону.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали: PD>У меня сегодня бессоница случилась. Проснулся часов в 6 и уснуть не смог. От нечего делать стал вспоминать эту дискуссию и обнаружил любопытный момент.
PD>Итак, я придерживаюсь двух догм. А ты не заметил, что эти две догмы взаимно исключают друг друга ? Ведь речь-то , по существу, об одном и том же идет — надо ли хранить длину ? Только в одном случае речь идет о строке символов, а в другом — о строке троек (i,j,val). PD>Придерживаться двух взаимоисключающих догм одновременно — это уж больно круто. Или же в этом нет ничего особенного — но тогда надо признать, что это не догмы. PD>Кстати, и ты здесь поворот на 180 градусов совершил. Для текстовых строк ты с жаром утверждал, что они просто обязаны хранить в себе длину, а вариант без длины, но с терминатором в конце (ASCIIZ) есть полный отстой и анахронизм. Теперь же вдруг выяснилось, что хранить с терминатором в конце — это правильно, а с длиной — нехорошо. Правда, речь идет не о символах , а о некоторых тройках чисел. Честно говоря, принципиальной разницы не вижу.
Я знал, я знал! PD>Заметь, я тебя вовсе не упрекаю в том, что ты в одном случае придерживаешься одной точки зрения, а в другом — другой. Более того, это правильно. Если ты в состоянии серьезно аргументировать, почему в одном случае надо так, а в другом — наоборот, то именно так и надо делать.
Совершенно верно. Критерий очень простой — практичность. Для большинства операций со строками крайне желательно знать длину в самом начале.
Для чтения/записи матрицы (нет никаких абстрактных троек чисел!) это не так.
Еще раз, сначала. Суть не в том, какие байты или биты мы храним. А в том, как мы их используем. Вот мы читаем матрицу. Предположим, что читаем мы ее с распаковкой в "обычное" представление. Что нам для этого надо? Выделить память. Ок, в самом начале сериализованного представления мы помещаем заголовок, в котором храним размер матрицы. Это полный аналог длины строки. Затем мы пишем компрессированный поток данных матрицы. У нас нет никакой задачи знать заранее длину этого потока. Зачем? Вполне достаточно искать терминатор.
PD>Есть некие данные, сильно или слабо структурированные. Их надо сохранить в файле. В одном случае достаточно сохранить их "как есть", так как структурированность их слабая (данные однородные). В другом случае данные неоднородные, а поэтому требуется завести некий управляющий блок, который и будет их структуру описывать, чтобы потом их прочитать можно было и структуру восстановить.Блок этот может быть очень простым (число троек в моем примере) или более сложным . http://www.google.ru/search?q=international+holidays+table PD>Обычно его помещают в начало файла, из-за чего вся проблема и возникает. Можно, конечно, его в конец файла поместить, тогда частично проблема будет снята, но — не поймут http://www.google.ru/search?q=international+holidays+tableВот, кстати — ты музыку в MP3 слушаешь? А как ты думаешь, в каком месте файла расположены теги жанра, категории и прочее? Вот ты употребил чудесную фразу "Обычно его помещают в начало файла, из-за чего вся проблема и возникает". Совершенно ты на сто процентов прав! Именно из-за этого проблема и возникает. В голове у тех, кто пытается все положить в начало. В том числе и то, что в начале никак не нужно. Просто из-за боязни, что "не поймут". Я даже слово подходящее для такого подобрать не могу. Здравый смысл рулит!
PD>1. Есть двумерная матрица цветов, размер ее известен. Надо сохранить ее в BMP-файл, 8 bpp. В зависимости от того, даст ли это эффект, сохранять надо ли в несжатом (BI_RGB), либо в сжатом (BI_RLE8) формате. Заголовок BMP-файла содержит 2 поля — BITMAPFILEHEADER.bfSize и BITMAPINFOHEADER.biCompression, которые зависят от того, будет ли сжатие или нет. Определить, будет ли сжатие можно только просмотром матрицы. Совершенно разумно провести этот просмотр, формируя при этом по ходу действия каждую строку в сжатом виде и выводя ее (либо же выводя исходную строку как есть). По окончании этого процесса станет ясным, использовалось сжатие или нет, какова длина получившегося файла, и байты карты будут уже на диске. Остается заполнить два поля в заголовке, вернуться в начало файла и записать заголовок.
Так, что-то я не понимаю. Флаг вроде один, а ты собираешься на ходу переключаться для каждой строки. Это невозможно. Ты сначала должен выбрать какой-то один вариант. В случае, если он оказался неудачным, тебе придется начать процесс заново, переписав не только хидер, но и сами данные, пережав их используя выбранный алгоритм. Или я что-то неправильно понял?
Насчет bfSize ты конечно же прав. Это как раз случай, когда архитектура победила здравый смысл. В итоге я не могу отдавать битмэп из http-хэндлера без предварительной записи его в буфер. Так это не сериализация плохая! Это RIFF — устаревший, плохой и неудобный формат. Но не надо путать формат BMP и задачу представления изображения. Формат — всего лишь одно из решений этой задачи. И особенно удачным я его назвать не могу.
PD>2. PE-формат. Там, как ты помнишь, полно вcяких RVA в заголовках. Заполнить их значения можно будет после того, как фактически весь PE-файл уже собран, так как для этого надо знать размеры секций, а их не определишь, пока весь граф не построишь. Не будешь же ты предлагать строить граф дважды — первый раз, чтобы определить размеры секций , а второй — для того, чтобы сами секции построить. Естественно, я не знаю, как линкер устроен внутри себя, действительно ли он однопроходной (там и другие факторы могут быть), но то, что ради этого никто лишний проход делать не будет — в этом я уверен.
Я тоже не в курсе, как работает линкер. К тому же их много разных. Современные скорее всего собирают весь файл в памяти. Кстати, насколько я помню, PE-формат проектировался еще для тех времен, когда важна была возможность посегментной загрузки. Я ничего не путаю? Если нет, то все правильно — я уже в третий раз могу сказать, что сериализация — не для случаев неполного чтения/записи.
PD>Честно говоря, даже странно тебе это объяснять. Ты прекрасно это понимаешь и сам, не могу допустить, что не понимаешь. И доведись тебе линкер писать — разумно бы и сделал, не сомневаюсь. Просто заклинило тебя тут — доказать, что алгоритм последовательного выкладывания такой уж хороший — вот ты и начал его совать туда, где он совсем ни к чему.
Павел, я пока никуда этот алгоритм не совал. Ты меня ни с кем не путаешь?
Тебе было интересно, каковы критерии применимости этого алгоритма — я пытаюсь их тебе объяснить. Ты с завидным упорством не видишь этих границ, и игнорируешь мои аргументы. Ты приводишь в качестве примеров задачи, где сериализация отлично подходит. Я ясно вижу, в каких местах ты апеллируешь не к задаче, а к решению. Которое вовсе не является единственным.
Я вот не буду цепляться за решение, оказавшееся неудачным. Не подходит матрица на хэш-таблице для алгоритма Якоби — и хеш с ней. Вернемся к массиву.
Но лучше все-таки подняться на шаг выше, и понять, что не старик Якоби наше начальство. Все наоборот — это мы привлекли его для выполнения задачи поиска собственных значений. И если он нас перестанет устраивать, то первым вылетит на помойку, а вместо него мы возьмем более быстрый алгоритм для трехдиагональных матриц. И совершенно случайно может оказаться, что этот алгоритм не загаживает разреженную матрицу значениями, а значит для него хеш имеет шанс выиграть за счет попадания в L2/L1 cache.
Но до всех этих мыслей, Павел, невозможно дойти, если сразу начать рассуждать в терминах какого-то специфического решения. В реальном проекте окажется, что кто-то будет реализовывать обратный fseek в потоке, который его раньше не поддерживал, только потому, что Павел Дворкин не моргнув глазом сказал "а без этого невозможно эффективно записывать разреженную матрицу". Ок, не все достаточно дотошны, чтобы копнуть поглубже и посмотреть, чем вызвана такая уж необходимость в fseek.
PD>А в самой идее именно сериализации (как алгоритма последовательного выкладывания) — ничего плохого нет. И применять его вполне можно. И даже нужно, так как он самый простой, а я твердо убежден в правоте принципа KISS. Только при одном условии — когда он уместен. А когда неуместен — не надо насиловать структуры данных, а надо просто иной алгоритм применить. Много их на свете — хороших и разных
Совершенно согласен. Но ты до сих пор не сумел даже наметить критерия этой применимости. Твоя интуиция, которой ты пользуешься, как мы имели шанс убедиться, промахивается в половине случаев. Лучше бросай монету Или все же попробуй сформулировать правило, которое однозначно определяет, подходит ли сериализация для решения определенной задачи.
PD>Ну если уж тебе так жизненно он нужен
Нет, Павел, это он тебе жизненно нужен. Я-то как раз знаю, где что применимо, а где что нет. PD>- расскажи, как будешь сериализовать мою матрицу цветов в BMP-файл с RLE кодированием.
Ты знаешь, все зависит от задачи. Если кровь из носу нужно писать именно BMP файл, то можно и fseek-ом воспользоваться. Отдавая себе отчет, конечно, в том, что ни для чего другого эта методика не подходит. А если я картинку между вебсервисами буду передавать, и речь будет идти о полиграфических размерах типа 8000*6000, то я потрачу куда больше времени на проектирование рабочего решения.
Понимаешь, нет никакого BMP. Это фикция, плод больного воображения людей, которые решали одну узкоспецифическую задачу.
Вот встань у меня задача сделать систему совместного редактирования изображений сверхбольших размеров — никаким BMP там даже рядом не запахнет. Потому, что его устройство плохо подходит для требований задачи.
А если мне надо в винде иконку в трей засунуть, то я не стану кровь из носу заниматься оптимизациями на уровне fseek. Там всех данных меньше, чем размер страницы файловой системы!
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Ну, извини. Что вижу, то и говрю. Обижать тебя ни малейшего желания не было.
Ok. Но если это повторится — вынужден буду прекратить дискуссию.
VD>Еще разок. Сериализация есть сохранение состояния объекта. Согласен, ты правильно уточнил, что в последовательную форму. Под последовательной формой тут понимается некая простая структура данных с которой можно легко манипулировать. Естественно, что такой структурой является плоский массив байтов или поток.
Ok.
VD>Еще раз хочу заострить внимание. Ключевое слово здесь сохранение состояния.
Если ключевое слово — сохранение состояния, а не в последовательную форму, то я готов немедленно согласиться и закончить дискуссию. Если сериализация есть сохранение состояния (в последовательную, индексно-последовательную, бинарное дерево, БД, zip-архив и т.д. и т.п) — я согласен и готов не спорить о терминах. Только вот по крайней мере MFC сериализация требует именно в последовательную форму. Насчет .Net — не берусь судить, не настолько хорошо знаю.
VD>"Выкладывание объекта в ряд" — это или пример извращеной терминалогии, или не понимания смысла процесса. Так что не нужно вообще так говорить.
Ok. См выше.
VD>Под "механизмом" ты понимашь алгоритм? Если да, то еще раз отсылаю к понятию абстракции. То как производится сериализация совершенно не важно. Важен результат. А он заключается в том, что сложно структурированный граф объектов превращается в последовательность байт.
Да бога ради, я на 100% согласен. В конце концов я ведь тоже в файл выкладывал, а он после закрытия уж на 100% последовательность байт, с этим не поспоришь. Я же совсем не об этом говорю, а о том, что сериализация, как она реализована (в MFC) требует, чтобы механизм (алгоритм) был последовательного выкладывания. Вот эта идея мне в общем случае не кажется верной.
VD>Естественно! Вообще многое не обязательно. Например, не обязательно выходить на улицу в одежде или при размышлениях пользоваться логикой.
Глупо. Аргументы подобного уровня заставляют только сомневаться в правоте аргументирующего.
>Нет сомнений, что пользоваться абстракциями не обязательно. Но как показывет практика отказ от нее приводит к печальным последствиям. Возможно на маленьких примерах это не сильно заметно. Но в масштабах большого приложения, а темболее несколькоих наплевательство на абстракцию обходится очень дорого.
Ох, надоело мне это упоминание больших проектов. Откуда тебе знать, в каких проектах я участвовал, что ты все время пытаешься мне это тыкать ? Проекта с суммарным размером исходников в 10 Мб хватит ?
VD>Именно по этому грамотные люди очень серьезно подходят к выбору абстрации и стараются соблюдать ее каноны. Структурное программирование и ООП собственно и бил созданы для этого.
Ну спасибо, просветил. Без тебя я про структурное программирование и ООП так и не узнал бы .
PD>> Если у меня никакая передача по сокету не предполагается, а предполагается только запись в дисковый файл, то я совсем не обязан писать код последовательного выкладывания, а вправе писать его как мне удобно.
VD>Ты не обязан вообще ничего. Но если ты разумный программист, то не будешь создавать проблемы себе и другим.
А я и не создавал. Код, который я писал, вполне успешно работает на сотнях компьютеров, и до сих пор никто не жаловался.
VD>Разумный программист отделит задачу сериализации от задачи записи в файл. Не разумный по капризу, недомыслию или в погоне за очередной оптимизацией может наплевать на абстракции и сделать несколько почти одинаковых решений отличающихся мелочами вроде способа записи.
Да уж, действительно мелочи. будет ли в результате файл размером в 10 Кб или 10 Мб, будет ли это работать быстро или медленно — это все мелочи. Зато принципы будут соблюдены.
VD>Сериализация вообще не является последовательным выкладыванием полей в поток (в прочем как и объетов). Сериализация — это преобразование состояния объекта в последовательную форму. То как это делается уже вторично. Ты можещь использовать разнообразные промежуточные структуры, сохранять только часть полей или даже некоторую функцию от состояния объекта по которой потом можно будет востановить это состояние. Это уже все детали. Главное, что в итоге ты должен получить массив байтов/поток в ктором находится состояние графа объектов.
В письме к Sinclair я сформулировал конкретно задачу (с матрицей). Напиши свое решение, обсудим. Хватит обо общих принциах говорить, код в студию.
VD>>>Вообще данный вопрс показывает то что большинство твоих проблем происходят из-за того, что ты не умешь мыслить абстракциями.
Меня, честно говоря, сильно удивляет то, что ты, вроде бы неглупый человек, столь несерьезно относишься к своим заявлениям. Неужели трудно понять из моих выступлений, что мыслить твоими любимыми абстракциями я умею, но для меня это лишь половина задачи. Наверное. что такое поток, я понимаю, но бездумно использовать эту концепцию, не разобравшись в том, как она может быть в данной ситуации реализована, я не буду.
Для тебя — есть объект, надо сохранить, выведем поток. Все ясно.
Для меня — есть объект, надо сохранить. Можно выести в поток, а это хорошо будет ? Размер файла ? Скорость ? Хорошо ? Тогда ладно. Нет ? А что другое можно предложить ? И т.д.
PD>>Меня принципиально не интересуют абстракции до тех пор, пока мне не ясна их имплементация.
VD>Вот это-то и плохо! Реализация не должна вообще рассматриваться в контесте выбора абстракции. Ведь одну и туже абстракцию можно реализовать разными способами.
А если ее нельзя реализовать в данной ситуации эффективно ? Нельзя, и все. А неэффективно — не принимается. Ваше решение ?
VD>Я тебе так скажу. Ты выдумал себе проблемы или создал их себе сам. У меня, например, особых проблем с производительностью нет. Все мои программы достаточно быстры. Точнее их производительность достаточна для решаемых задач.
У меня их тоже нет.
VD>Кстати, если уж говорить о производительности, то хочу заметить, что чень смешно наблюдать как ты рассуждашь тут о реализации сериализации и при этом в соседнем форуме видно, что ты изучаешь и используешь НКибирнэйт. Воможно ты не знашь... дело в том, что НКибирнэйт — это O/R Mapper. А O/R Maping — это саое не эффективное средство работы с данными хранящимися в БД. Удобная, высокоуровневая, но принципиально неэффективная. Обычно решения основанные на O/R Maping-е приблизительно в 10 раз менее эффективны чем аналогичные исползующие прямую работу с БД. Заметь, я не отговриваю тебя от использовани НКибирнэйта. Я просто замечаю, что твоя борьба за производительность очень странно выглядит.
Вообще забавно смотреть на твой менторский тон. "Возможно, ты не знаешь..." и дальше популярное объяснение. Знаю, не волнуйся. И не изучаю, а закончил небольшой проект на нем. Увы, заказчик потребовал использовать NHibernate. Клиент всегда прав, как известно. Ну что же, по крайней мере я постарался сделать так, чтобы запросы к БД были не менее эффективными, чем на чистом SQL.
Кстати, разъясни фразу "приблизительно в 10 раз менее эффективны, чем аналогичные исползующие прямую работу с БД". Ты утверждаешь, что у меня в 10 раз больше данных выбирается, или в 10 раз больше модификаций делается, или что ? Если это — можешь быть уверен, что это далеко не так, ничего лишнего там выбираться не будет.
VD>Небывает уровеня реализации. Быают разные реализации абстракций и (иногда) алгоритмические ограничения абстракций. Например, связанный список накладывает принципиальные ограничения на скорость последовательного доступа. Вот только сериализация то тут причем?
Не знаю. Я могу еще заявить, что скорость ввода символов с клавиатуры человеком накладывает принципиальные ограничения на возможность вручную ввести "Войну и Мир" за одни час, и спросить — а при чем здесь сериализация? Ты задал этот вопрос, ты и отвечай. Я про связанные списки вообще ничего не говорил.
PD>> Мыслить абстракциями я вполне могу, но найдя решение на уровне абстракций, я тут же задам себе вопрос — а как это будет на уровне реализации ?
VD>К сожалению, лично я вижу что ты сваливашь в одну кучу абстракцию и реализации, а потом пыташся в этом всем разобраться.
Да давно я во всем этом разобрался. Твоя ошибка в том. что ты почему-то решил, что мне неизвестны элементарные истины, и пытаешься меня им научить, А для меня эти истины — просто нечто рабочее, о чем я и думаю-то мимоходом. Стек так стек, поток так поток, дерево так дерево. Все замечательно. А теперь давайте думать — а как это сюда уляжется. С этим потоком мне уютно будет ? Нет ? А куда выводить надо, только в файл ? Да, А тогда долой отсюда этот поток. В файл я и по-другому записать могу. Вот и все.
PD>> И если абстракция хороша, а реализовано эффективно быть не может в данной задаче — на помойку такую абстракцию, поищем другое решение. По крайней мере для реальных программ и реальных машин. А абстракции, которые не имеют эффективной реализации в данной ситуации я оставляю тем, кто иначе писать не умеет.
VD>В том-то и дело, что вопрсы оценки характиристик абстрации не связаны с вопросами ее реализации. Одна и та же обстракция может быть реализована более или менее эффективно. А оценить пригодность абстракции можно ничего не зная о ее конкретной реализации.
Да ? Ну хорошо.
Вот тебе абстракция — линейный список с возможностью доступа по индексу к имеющимся элементам ? Годится абстракция ?
А теперь ответь — можно ли использовать эту абстракцию для хранения данных, если
a)
1) количество элементов очень велико
2) операции вставки/удаления в начало производятся очень часто
3) операции доступа по индексу производятся очень редко
4) скорость работы критична
б)
1) количество элементов очень велико
2) операции вставки/удаления в начало производятся очень редко
3) операции доступа по индексу производятся очень часто
4) скорость работы критична
Непременное условие — о реализации ты ничего не знаешь, как ты и хотел. Иными словами, после того, как ты ответишь на оба вопроса, я тебе сообщу, какая именно реализация используется в библиотеке, которую ты должен использовать.
И просьба не отвечать — дескать, если меня не устроит эта реализация, я другую сделаю. Нет у тебя такого права.Ты сам от него отказался.
Только просьба — ответь прямо — да или нет ? Ты же говоришь — оценить пригодность абстракции можно ничего не зная о ее конкретной реализации, так ? Ну вот и оцени — пригодно или нет.
VD>Более того, ты делашь массу предположений основное количество которых не подкреплено никакими фактами. Ты думшь, что А медленно, а Б быстро. Но на самом деле все может оказаться совсем не так. Как в том самом случае с чтением файлов по байтам. Поробуй как-нить на досуге прочитать побайтно файл в дотнете через его абстракции.
VD>В общем, я не понимаю, как можно не понимать стольк простых вещей.
Я тоже.
VD>Ну, нет никаких проблем для того, чтобы эффективно сериализовать все что угодно в поток байтов. Ну, нет! Ты можешь банально сделать это в помяти и вернуть требуемый интерфейс воспользовавшись каким-нибудь MemoryStream.
Памяти нет
>Так зачем же жертвовать абстракцией и писать какие-то частные клагоритмы которые можно использовать только в отдельных случаях?
Для того, чтобы самолет летал быстрее, чем паровоз ездит
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Ну слава богу, хоть их существование признано.
А я их существование и не опровергал.
но сойдет. S>>Павел, а ты заметил, что подменил задачу? До сих пор ты вроде как говорил о персистентности, т.е. сохранении объекта с целью его последующего восстановления. S>>А теперь вместо восстановления объекта ты перешел к выполнению запросов. PD>Нет, Речь идет о сохранении матрицы со средними значениями в файл для последующего чтения ее из файла с пропуском тех строк, которые нам не нужны. Где здесь запросы ?
Вот здесь они и есть. Если нам заранее известно, какие строки нам не нужны, мы можем их просто не сохранять. Вуаля.
А задача "прочитать все строки, которые удовлетворяют некоторому условию" — это и есть выполнение запроса. Обрати внимание, что обратно ты читаешь вовсе не матрицу. Обратно ты читаешь что-то совсем другое.
S>>Так вот я тебе открою тайну: никто и не применяет сериализацию для выполнения запросов. PD>Термин запрос в твоем изложении мне не ясен, поэтому будь добр объяснить, что ты под ним понимаешь. В моем понимании здесь запросов нет.
Все очень просто. У нас есть некоторое множество объектов, и есть пользовательский предикат P над этим множеством. Выполнение запроса суть построение подмножества исходного множества, помещая в него только объекты, удовлетворяющие этому предикату. В твоем случае объект — это строка матрицы; предикат — AVG(Cell)>K.
PD>Для этого есть движки различной степени специализированности. Ты почему-то решил, что кто-то чем-то злоупотребляет. Нет, это ты злоупотребляешь fseek-ом там, где хватило бы оператора <<.
PD>Нет, это именно те, кто столь любят сериализацию, злоупотребляют ею, плодя при этом файлы длины в N раз больше чем надо и захватывая ОП там, где это совсем не надо.
А какое отношение длина файла имеет к сериализации? Ты что, думаешь что fseek волшебным образом ее сократит? Разве что если ты две матрицы поверх друг друга запишешь
Пример злоупотребления сериализацией в студию. Пагубность твоего матричного сериализатора я тебе уже показал.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>О да. Так можно очччень сереьещную теорию подвести под самую заурядную проблему.
А ты как думал? Хорошо, если тебе не нравится термин "выполнение запросов", сократим до более инженерного определения:
"сериализация не подходит в том случае, если необходимо частичное чтение или запись данных".
Все. Это простое правило даст тебе всю необходимую информацию для принятия правильного решения в большинстве случаев.
На самом деле, конечно, сериализацию можно применять и для частичного чтения — все зависит от селективности. Если пропускается одна строка из тысячи, отказываться от успешно работающего сериализационного алгоритма смысла нет. А если надо выбрать из тысячи одну, то и твое предложение хранить средние в начале строк будет чудовищно неэффективно. Вместо этого опытные собаководы организуют B-tree, которое учитыват неодинаковую полезность fseek в различные места файла. S>>А какое отношение длина файла имеет к сериализации? PD>Самое непосредственное. При этом будут записаны ненулевые элемениы только. В один проход. И размер волшебным образом сократится — расчеты я сегодня утром приводил, то ли в письме к тебе, скорее к VladD2, посмотри сам.
Я тебе уже привел тот же результат при сериализации. Предпочитаешь игнорировать опровержения? Молодец.
PD>Сериализация в memory stream и десериализация обратно для детального клонирования объета. Примеры у Рихтера.
Хм. Решение как решение. Применили готовый механизм для решения еще одной задачи. В очень многих случаях делать отдельное клонирование не потребуется — единственное, что может нам помешать, это соображения производительности. А их заранее лучше не привлекать — можно и в лужу сесть. >>Пагубность твоего матричного сериализатора я тебе уже показал. PD>Я бы добавл с твоей строны — ИМХО. Не стои так уж выдавать свое мнение за истину в последней инстанции. Ты все же не заместитель господа бога по программированию, чтобы разбрасываться такими словами.
Какими словами? Павел, здесь все просто — ты приводишь задачу, приводишь ее решение. Я привожу свое решение. Причем тут господь бог? Есть объективная реальность, данная нам в ощущениях. Твое решение хуже поддается улучшениям, не давая никакого выигрыша ни по объему данных, ни по производительности.
Другой человек (я, например) в такой ситуации задумался бы над пересмотром своих решений.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Глубокий смысл в том, что для включения сериализации для класса тебе надо написать всего одну строчку кода — указать SerializableAttribute для класса и всё. После этого сериализация/десериализация будет делаться автоматически и тебе не прийдётся для каждого класса писать кастомный код сериализации ручками.
Здравствуйте, Oyster, Вы писали:
O>Глубокий смысл в том, что для включения сериализации для класса тебе надо написать всего одну строчку кода
К сожаленгию, у всего есть обратная сторона.
Аккуратно ручками написанная сериализация через BinaryWriter/BinaryReader примерно в 100 раз быстрее работает чем эта.
Ес-но, в 99% случаев достаточно и производительности, которую обеспечивает стандартные механизм
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, GSL, Вы писали:
GSL>но с датой которая только get это почти невозможно, почти потому, что столько ограничений, что проще использовать Write/Read, особенно если говорить о XML.
Для таких случаев можно использовать не Write/Read, а паттерн memento.
(где в свою очередь использовать стандартный XmlSerializer)
Здравствуйте, Poluekt, Вы писали:
P>я помню что это Ойстер был. однако ты сам вызвался позвать В2
Я?! Где?
P>писать реплики на статью нет смысла.
Как раз только в этом и есть смысл. Абсолютно правильных и верных статей практически не бывает, большинстве своем они нужаются в замечаниях и корректировках и единственно верный способ как-то эти корректировки внести и указать на ошибки автору — обсудить в форуме его статью.
Откровенную фигню стараемся не пропускать, знал бы ты что к нам приходит, но остальное — на вашей совести...
P> на самом деле должен быть "редактор" который бы фильтровал базар.
На самом деле их человек 15, отвечающих за техническую грамотность и регулярно вычитыващих различные статьи. (правда всех пинать приходятся, ленятся потамушта). Очевидно, с их точки зрения статья достойная как минимум опубликования.
Не согласны? Обсудим, не вопрос — именно для этого форумы к статьям и прикручивали.
P>но я в рсдн никого не знаю.
А не надо никого знать. Надо пользоваться предоставленой возможностью по критике произведения.
Откровенно говоря, мне жаль, что я начал опять с тобой дискуссии. Не умеешь ты нормально дискутировать Так что этот ответ опять будет последним.
>Нет никакого выкладывания объектов в линию. Есть сериализация — сохранение состояния объекта.
Serialization Преобразование в последовательную форму
Это мне словарь выдал (Socrat 4.1)
Не любое сохранение состояния объекта есть преобразование в последовательную форму. Я могу, к примеру (вольная фантазия), сохранить массив в бинарное дерево, если мне такое вдруг захочется. Надеюсь, ты не будешь возражать, что из бинарного дерева я смогу восстановить массив ? Означает ли это, что преобразование массива в бинарное дерево есть сериализация ? Означает ли это, что любая запись объекта в базу данных (безусловно сохранение состояния объекта) есть сериализация ?. Так ведь под сериализацию можно все, что угодно подвести.
Это во-первых. Во-вторых, речь шла не о том, выкладывать или нет в линию, а , подчеркиваю, о механизме этой операции. И механизм этот в общем случае не является последовательным. И не надо аргументировать это тем, что дескать, общие принципы должны соблюдаться независимо от типа destination. Это совсем не обязательно. Если у меня никакая передача по сокету не предполагается, а предполагается только запись в дисковый файл, то я совсем не обязан писать код последовательного выкладывания, а вправе писать его как мне удобно.
Впрочем, если ты готов признать, что сохранение сотояния объета не означает обязательно последовательное выкладывание его полей в поток, а может быть реализовано так, как мне удобнее — я готов о терминах не спорить и согласиться.
VD>Вообще данный вопрс показывает то что большинство твоих проблем происходят из-за того, что ты не умешь мыслить абстракциями.
Меня принципиально не интересуют абстракции до тех пор, пока мне не ясна их имплементация. Именно благодаря тому, что некоторые программисты предпочитают мыслить абстракциями, не задумываясь о том, как будет все это реализовано, мы и имеем то плачевное состояние с производительностью, о котором я писал полгода назад. Повторяться на эту тему я не буду.
>Ты все время пыташся влезть в реализацию и сделать далеко идущие выводы. Это будет всегда мешать тебе решать действительно сложные задачи, так как без введения абстракции и оперирования ими сложность будет непомерно высока.
Нет. Это лишь дает мне возможность искать правильное решение — и с точки зрения высокого уровня (абстракций) и с точки зрения низкого уровня (реализации). Мыслить абстракциями я вполне могу, но найдя решение на уровне абстракций, я тут же задам себе вопрос — а как это будет на уровне реализации ? И если абстракция хороша, а реализовано эффективно быть не может в данной задаче — на помойку такую абстракцию, поищем другое решение. По крайней мере для реальных программ и реальных машин. А абстракции, которые не имеют эффективной реализации в данной ситуации я оставляю тем, кто иначе писать не умеет.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>В конечном счете речь идет о сохранении чего-то в файле (я не забыл про всякие memory stream, но опустим их пока что). S>Это заблуждение. Сериализация никак не связана с файлом. Сериализация — преобразование в последовательное представление. Где здесь упоминание про файл? Нету. Упс. Не надо додумывать единственное решение к сложной проблеме.
Ну и не надо. Вполне согласен. А вот надо ли при записи в файл использовать сериализацию ? Т.е преобразование в последовательное представление. Или же можно записать в файл без преобразования в последовательное ? В это и вопрос.
S>А зачем делать вот это туда-сюда? Вместо этого можно придумать маркер конца матрицы (например, -1, который не может быть валидным row).
Не понял, зачем мне какая-то -1 здесь вообще нужна.
S>Если смущает необходимость перевыделять память для матрицы при чтении
Не понял, зачем мне вообще при выводе матрицы в файл что-либо перевыделять. Эта задача решается на O(1) по памяти.
>, то я вообще уже ничего не понимаю: если мы собираемся десериализовывать матрицу в квадратное неразреженное представление, то нам вообще длина не нужна.
А где я про длину говорил ?
>А если она и в памяти разреженной хранится, то непонятно, почему она не знает свой размер в самом начале сериализации.
Sinclair, разберись как следует , о чем я говорил. При чем тут размер матрицы ? Речь идет о выводе ее на диск. Исходная матрица разреженная. Размер ее прекрасно известен. Сколько там ненулевых элементов — неизвестно. Надо вывести матрицу в простейшем формате — сначала число ненулевых элементов, затем тройки (i,j, value).
1. Дополнительная память — не более, чем O(1). Прямо или косвенно.
2. Двухпроходной алгоритм не рассматривается.
Все. Можешь сделать это с сериализацией — давай сюда код.
>В общем, в очередной раз я вижу победу оптимизации над здравым смыслом, которую я уже наблюдал в топике про длину строк. И опять же приходит мне на ум проблема преподавания, которая приводит к таким результатам — ты замечательно видишь отдельные деревья, но напрочь отказываешься видеть лес.
Вот и напиши код для леса. Или для дерева.
S>Конечно, во времена ДОС все было прекрасно. А в наше время приходится регулярно работать с объектами, не поддерживающими произвольный доступ.
А если объект не поддерживает произвольный доступ, то все мои возражения автоматом снимаются. Потому как кроме как о файле, я ничего и не утверждал. А он поддерживает.
>Если ты научил свой объект сериализовываться, то внешний код может воспользоваться этим для сохранения в файл на диске, >сохранения в файл на ftp-сервере, пересылке по сети, да еще в сотне контекстов. В том числе есть и очень важное умение: сохранение в поток можно делать рекурсивно. Т.е. если у нас есть набор объектов, каждый из которых умеет сохраняться в поток, то и весь набор автоматически умеет сохраняться в поток.
Это все прекрасно и чудесно, вот только в данной конкретной задаче, допустим, все это не нужно. Не нужно и все. Не требуется. Все равно будем сериализовать ?
>А вот организовать что-то полезное из агрегата "файлоумеющих" объектов не удастся, потому что каждому нужен отдельный файл.
Это что-то новое ? Ты хочешь сказать, что я не смогу таким способом записать 2 объета в один файл. Ну что же, возьми мой пример и запиши 2 матрицы в один файл. Совершенно элементарно делается. Или еще-что записать. Никаких проблем не будет. Делал , и не раз.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>>В конечном счете речь идет о сохранении чего-то в файле (я не забыл про всякие memory stream, но опустим их пока что). S>>Это заблуждение. Сериализация никак не связана с файлом. Сериализация — преобразование в последовательное представление. Где здесь упоминание про файл? Нету. Упс. Не надо додумывать единственное решение к сложной проблеме.
PD>Ну и не надо. Вполне согласен. А вот надо ли при записи в файл использовать сериализацию ? Т.е преобразование в последовательное представление. Или же можно записать в файл без преобразования в последовательное ? В это и вопрос.
Для записи в файл нужны только операции записи в файл.
Только причем тут это?
PD>Пример
PD>0 1 0 1 7 PD>1 0 1 0 0 PD>0 0 4 0 5 PD>2 0 0 0 1
PD>Результат в файле
PD>9 PD>011 PD>031 PD>047 PD>101 PD>121 PD>224 PD>245 PD>302 PD>341
PD>Вот и выведи. Условия
PD>1. Дополнительная память — не более, чем O(1). Прямо или косвенно. PD>2. Двухпроходной алгоритм не рассматривается.
PD>Все. Можешь сделать это с сериализацией — давай сюда код.
Проблема видимо только в первом элементе "число ненулевых элементов"
Его можно писать в конце.
Или еще можно размерность матрицы в начало писать.
Здравствуйте, Sinclair, Вы писали:
PD>>Sinclair, разберись как следует , о чем я говорил. S>Ок, но от тебя ожидаю того же. PD>>При чем тут размер матрицы ? Речь идет о выводе ее на диск. Исходная матрица разреженная. Размер ее прекрасно известен. Сколько там ненулевых элементов — неизвестно. Надо вывести матрицу в простейшем формате — сначала число ненулевых элементов, затем тройки (i,j, value). S>ЗАЧЕМ выводить сначала количество ненулевых элементов? Придумали себе геморрой, а потом с ним мужественно боремся? PD>>Вот и выведи. Условия ... Все. Можешь сделать это с сериализацией — давай сюда код. S>Вывожу. По буквам: S>
S>Вот и всех делов. Здорово, правда? Никакой лишней памяти, никакого лишнего времени, и никакого требования поддерживать произвольный доступ.
Нет, ничего особенно хорошего не вижу. В данном случае ты нашел не слишком элегантное решение. Но оно не будет работать, если допустить , что нумерация строк матрицы не с нуля, а произвольная. И во многих других случаях тоже — можешь их сам придумать. Посмотри, кстати,мое письмо к bkat — я там модификацию способа хранения изменил. Ее, конечно, тоже можно в твое ложе уложить, но красиво не будет...
PD>>А если объект не поддерживает произвольный доступ, то все мои возражения автоматом снимаются. Потому как кроме как о файле, я ничего и не утверждал. А он поддерживает. S>Еще раз: вменяемые люди стаарются применять наиболее доступные технологии. Произвольный доступ используется там, где без него нельзя обойтись. Например, в СУБД — там используется страничная организация файла, позволяющая не только читать, но и писать его по частям без нарушения внутренней целостности. Но СУБД и не собираются работать с данными по HTTP.
Вменяемые люди используют то, что им надо в конкретной ситуации. Если я пишу графический редактор, к примеру (доводилось), а в нем надо сохранять во временный файл рабочие данные, которые мне и в страшном сне не приснится посылать в сеть, то незачем создавать себе проблемы и думать о том, что будет при пересылке его по сети. Поэтому если я смогу их сохранять при последовательном доступе — так и сделаю. Нет (медленно, слишком большой файл и т.д.) — будет прямой доступ.
S>Что не требуется? Компаунд-объекты? Сегодня не требуется, а завтра потребуется. Все, твоя матрица уехала на помойку, а ты икаешь, т.к. тебя вспоминает недобрым словом тот, кто вынужден переписывать твой код, потому что начальство захотело сделать веб-сервис для матричных операций, а твоя матрица при попытке отдать ее по сети кидает invalid operation exception.
А давай уточним твою посылку.
Произвольный доступ используется там, где без него нельзя обойтись.
Итак, ты утверждаешь, что при определенных условиях произвольный доступ допустим ? Отлично! Но тогда почему ты меня лишаешь права его использовать ? Если я БД буду писать — ты не возражаешь. А если что-то иное — ты против.
Откуда тебе знать, что я пишу ? Может, здесь это еще больше имеет смысл, чем при написании БД!
Вот и все. Ларчик просто открывался.
PD>>Это что-то новое ? Ты хочешь сказать, что я не смогу таким способом записать 2 объета в один файл. Ну что же, возьми мой пример и запиши 2 матрицы в один файл. Совершенно элементарно делается. Или еще-что записать. Никаких проблем не будет. Делал , и не раз. S>Это означает, что на самом деле представление все же сериализованное — ведь матрицы лежат друг за другом. Никакого преимущества твой способ в итоге не дает, зато не умеет передаваться по сети.
Ну несерьезно же. Естественно, они лежат подряд, файл все же, и без "дырок" или специальной структуры. Представление — да, сериализованное. Способ вывода — нет. А я только о способе выода и говорю в этой дискуссии.
Pavel Dvorkin wrote: > Если ключевое слово — *сохранение состояния*, а не *в последовательную > форму*, то я готов немедленно согласиться и закончить дискуссию. Если > сериализация есть сохранение состояния (в последовательную, > индексно-последовательную, бинарное дерево, БД, zip-архив и т.д. и т.п) > — я согласен и готов не спорить о терминах. Только вот по крайней мере > MFC сериализация требует именно > *в последовательную форму*. Насчет .Net — не берусь судить, не настолько > хорошо знаю. > > VD>"Выкладывание объекта в ряд" — это или пример извращеной > терминалогии, или не понимания смысла процесса. Так что не нужно вообще > так говорить.
Serialization от слова "serial" — "последовательный". Сериализовать можно не с целью сохранения состояния, а, например,
для передачи по сети.
Если же сохранение состояния, то persistence.
В поток сериализуют, а в БД персистят.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
И, кстати, а зачем вообще хранить длинну? Элементы фиксированной длинны. Размер матрицы известен. Читай себе пока элементы не кончатся и востанавливай значения ячеек.
Хотя это конечно частный случай. Одако не вижу проблем в том, чтобы сформировать нужный список в памяти, а потом записать в конечный покто количество элементов (если уж действительно нужно), и за ним скопировать поток.
И не надо рассказывать про скорость и лишнюю память. Память ты занимашь на наносекунды. Объем ее незначителен. Любое использование сериализованной информации (предача через сеть, запись в файл...) несоизмеримо со скоростью копирования памяти.
ЗЫ
И, кстати, натянутость самой ситуации снова настораживает. Значит при хранинии данных в памяти (которая как извесно примерно на 3 порядка дароже) ты выбирашь плоские массивы, а при хранении на диске вдрг слезно озаботился компактностью. Странно это.
Скорее всего матрица просто не самое эффективное представление данных. Или нужно использовать хэш-таблицу, или еще что-то. А при этом и слгоритмы сериализации опменяются.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Уф, наконец-то первое здравое размышление в этой дискуссии. Я же именно об этом и говорю. Я разве против сериализации, когда она оправдана алгоритмом ? Ни в коем случае, я целиком за!!! Я против того, что сериализация бездумно используется там, где алгоритм ее вовсе не предполагает. Например, для копирования объекта в памяти. Например, для вывода объекта на диск при том, что этот вывод достаточно сложен и не укладывается в один линейный проход. И т.д.
Пример со сложным выводом в студию. Желательно реальный. Это должно быть легко — ведь в твоей практике такие выводы встречаются куда чаще, чем линейные, не так ли? PD>Меня не сериализация беспокоит. Сама по себе она вполне законный метод, безусловно имеющий право на существование. Мне не нравится, когда ее применяют там, где совсем не надо. А тем более пытаются доказать, что применять ее все же стоит даже в тех случаях, когда она явно противоречит алгоритму (последнее утверждение есть непосредственно камешек в твой и Sinclair огороды)
Павел, в моем огороде их уже и так достаточно. Пока что ты не привел ни одного алгоритма персистенса, который бы противоречил сериализации. Я вот могу их привести. Но они настолько далеки от твоей ситуации, что пока что мы это оставим. Вплоть до момента, когда на тебя снизойдет просветление, и ты наконец поймешь, что бесчисленные преимущества сериализации перевешивают те лишние 40 секунд, который надо потратить на перепроектирование алгоритма "записи конем". PD>В общем, не сотвори себе кумира из сериализации. Да и из всего другого тоже.
В общем, не изобретай сущностей без необходимости. В частности, не требуй для персистенса произвольного доступа.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Пожалуйста, я его уже приводил. Матрица та же. Для каждой строки должно быть выведено среднее ее элементов, так как в зависимости от его значения эти строки будут потом вводиться или нет. Читать с диска строки, для которых m < некоторого K, не разрешается, они просто должны при вводе пропускаться.
Ага, вот мы начинаем постепенно подходить к тем задачам, для которых действительно сериализация не подходит. PD>Сложным этот пример не назвать, но сойдет.
Павел, а ты заметил, что подменил задачу? До сих пор ты вроде как говорил о персистентности, т.е. сохранении объекта с целью его последующего восстановления.
А теперь вместо восстановления объекта ты перешел к выполнению запросов.
Фактически, уже здесь лежит граница. Как только мы ставим себе задачу научиться читать не все, приходится мгновенно отказаться от сериализации. Потому, что она и при чтении позволяет читать только вперед, никаких прыжков "мимо строки" в ней нет.
Следующим этапом будет "минимизировать время внесения изменения в одну ячейку матрицы от чтения до записи на диск", и тебе не помогут даже фокусы с fseek. Потому что они подходят только для данных, длина которых известна.
Так вот я тебе открою тайну: никто и не применяет сериализацию для выполнения запросов. Для этого есть движки различной степени специализированности. Ты почему-то решил, что кто-то чем-то злоупотребляет. Нет, это ты злоупотребляешь fseek-ом там, где хватило бы оператора <<.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ага, вот мы начинаем постепенно подходить к тем задачам, для которых действительно сериализация не подходит.
Ну слава богу, хоть их существование признано.
PD>>Сложным этот пример не назвать, но сойдет. S>Павел, а ты заметил, что подменил задачу? До сих пор ты вроде как говорил о персистентности, т.е. сохранении объекта с целью его последующего восстановления. S>А теперь вместо восстановления объекта ты перешел к выполнению запросов.
Нет, Речь идет о сохранении матрицы со средними значениями в файл для последующего чтения ее из файла с пропуском тех строк, которые нам не нужны. Где здесь запросы ?
S>Так вот я тебе открою тайну: никто и не применяет сериализацию для выполнения запросов.
Термин запрос в твоем изложении мне не ясен, поэтому будь добр объяснить, что ты под ним понимаешь. В моем понимании здесь запросов нет.
Для этого есть движки различной степени специализированности. Ты почему-то решил, что кто-то чем-то злоупотребляет. Нет, это ты злоупотребляешь fseek-ом там, где хватило бы оператора <<.
Нет, это именно те, кто столь любят сериализацию, злоупотребляют ею, плодя при этом файлы длины в N раз больше чем надо и захватывая ОП там, где это совсем не надо.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Боюсь, флейм сейчас начнется. Ну да ладно
PD>В конечном счете речь идет о сохранении чего-то в файле (я не забыл про всякие memory stream, но опустим их пока что). А файл (не file Виртовского паскаля, а натуральный файл) есть структура прямого доступа вообще-то. К персистентности у меня никаких возражений нет, но почему эту персистентность надо делать, записывая данные именно последовательно — это я в общем случае не понимаю (в частных случаях вполне могу быть согласен).
PD>Сохранять данные последовательно во многих случаях вполне разумно. В других — ИМХО совершенно неразумно, так как их сохранение по природе своей не есть выкладывание в линию. Иногда лучше сначала зарезервировать в файле некоторое место, просто не записать туда ничего, выложить в файл все остальное, потом вернуться туда и записать пропущенное. К примеру, разреженную матрицу ИМХО именно так и следует записывать — оставить место для количества ненулевых элементов (4 байта), выложить все тройки (row,col,value), по ходу действия подсчитав их количество, потом спозиционироваться на место для этих 4 байтов и записать это количество. Можно, конечно, в 2 прохода сделать, тогда будет именно сериализация, но, простите, зачем ? Во имя принципов ?
PD>Лично мне в моей работе пришлось однажды заняться тем, что можно назвать "выкладывание в файл". Но вот сериализацией назвать это язык не поворачивается. Потому что там создавались довольно сложные структуры, частями записывались в файл (хранить в ОП не мог — там десятки и сотни Мб), потом в файле я возвращался назад, заполнял их блоки управления, потом опять назад, заполнял блоки управления более высокого уровня и т.д.
PD>А вообще должен сказать, что никогда никаких проблем с записью в файл у меня не было. Еще в DOS времена как освоил fopen-fwrite-fread-fseek-fclose, так до сих пор и пользуюсь. Ну разве что иногда перехожу на CreateFile etc. И, конечно, файл-мэппинги. Как, кстати, насчет их ? Там ведь, по большому счету, то же выкладывание в файл идет (если надо файл сохранить, конечно), только вот кому захочется при работе файл-мэппингом запретить себе свободно перемещать указатель — я посмотреть бы хотел.
На самом деле в управляемых средах сериализацию ввели не для того, чтобы сохранять что-то в файлах, а для Remote-интерфейсов. А в файлы, которые есть долговременные хранилища — приходится писать сериализацию ручками, чтобы быть независимыми от версии. Причем крайне желателен текстовый формат (типа XML), чтобы не зависить не только от структуры отдельного класса, но и от их совокупности (грубо говоря есть Клиент, у него Адреса, в адресе еще что-то и т.д. и т.п.). Так что стандартная сериализация она не в файл, а по сети )))
P.S. пишем на Java, опять же, выше мое лично мнение, основанное на опыте и борьбе с граблями
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Все очень просто. У нас есть некоторое множество объектов, и есть пользовательский предикат P над этим множеством. Выполнение запроса суть построение подмножества исходного множества, помещая в него только объекты, удовлетворяющие этому предикату. В твоем случае объект — это строка матрицы; предикат — AVG(Cell)>K.
О да. Так можно очччень сереьещную теорию подвести под самую заурядную проблему.
S>А какое отношение длина файла имеет к сериализации? Ты что, думаешь что fseek волшебным образом ее сократит? Разве что если ты две матрицы поверх друг друга запишешь
Самое непосредственное. При этом будут записаны ненулевые элемениы только. В один проход. И размер волшебным образом сократится — расчеты я сегодня утром приводил, то ли в письме к тебе, скорее к VladD2, посмотри сам.
S>Пример злоупотребления сериализацией в студию.
Сериализация в memory stream и десериализация обратно для детального клонирования объета. Примеры у Рихтера.
>Пагубность твоего матричного сериализатора я тебе уже показал.
Я бы добавл с твоей строны — ИМХО. Не стои так уж выдавать свое мнение за истину в последней инстанции. Ты все же не заместитель господа бога по программированию, чтобы разбрасываться такими словами.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Еще как забавно! Настолько забавно, что мне даже неудобно объяснять. PD>>Матрица является разреженной на входе. Как только начнется диагонализация, матрица разреженной быть перестанет. И во время этого процесса хранить ее надо целиком. К концу диагонализации, правда, матрица опять станет почти разреженной. Точнее, на диагонали будут собственные числа, а недиагональные элементы будут близки к нулю. Близки, но не равны — алгоритм Якоби приближенный, итерационный. И хранить эту матрицу придется до тех пор, пока мы эти собственные числа куда-нибудь не заберем, а матрицу уничтожим.
S>Прикольно. Я правильно понимаю, что этих близких к нулю можно смело убить, т.к. это погрешности алгоритма?
Слушай, ну возьми книгу по выч. методам и посмотри алгоритм Якоби! Близкие к нулю образуются только когда итерационный процесс закончится. До этого они не близки к нулю А результат диагонализации — вектор собственных значений. Линейный вектор, понимаешь ? Он после окончания итерационного процесса расположен на диагонали матрицы. В конечном счете надо по матрице получить вектор (о получении еще и матрицы собственных векторов я сейчас не говорю, это еще одна матрица, но это не всегда требуется, хотя вообще-то получается в том же алгоритме). А убивать их не надо — убить надо всю матрицу, так как работа закончена, и она больше не нужна.
PD>>Если тебе угодно хранить целиком матрицу N*N в виде хеш-таблицы и для каждого обращения к ее элементу (внутри тройного цикла!) лазить в эту таблицу — бог тебе в помощь. А вообще даже интересно бы сравнить — во сколько раз можно здесь получить проигрыш. Я думаю (не утверждаю, а только думаю) — раз в 5 как минимум, а то и 10. S>Да, интересно. Будет время — сравним. Мне почему-то кажется, что для сильноразреженных матриц даже промежуточные результаты диагонализации содержат много нулевых элементов.
Я на этом когда-то собаку съел, правда, вкус ее давно забыл. Во-первых, там все наоборот — иногда даже переполнения случаются. Помнишь, как-то я тебя спрашивал — можно ли в обработчике исключения "исправить" ошибку и приводил пример расширенной обработки ошибок на фортране ЕС ? Так вот, там как раз в процедуре EIGEN это и происходило. Помню, долго я с этим боролся, портируя на БЭСМ-6, где такого не было. Давно это было. Эх...
Во-вторых — будут они близки к нулю или нет — а не все ли равно ?. Ты что, предлагаешь каждое вновь вычисленное значение a[i,j] сравнивать на близость к нулю (еще вопрос — по какой погрешности) и если близки — совать в хеш-таблицу, а иначе из нее удалять (он ведь раньше там был, и ненулевой). Это уж совсем чудовищно будет.
S>>>не слишком заботясь о низкоуровневой производительности.
PD>>Именно это я и вижу у тебя и VladD2. Не слишком заботясь о производительности (слово низкоуровневой здесь существенной роли не играет).. Именно это я и наблюдаю — с соответствующим результатом. Ты усвоил, что есть такой "паттерн" — хранение матрицы в виде хеш — таблицы (вполне применимый в определенных случаях) — и теперь, не думая, что из этого выйдет, суешь его туда, где он совершенно неприменим. S>Павел, ты опять бредишь.
Антон, прекрати подобный тон, или я прекращу участие в дискуссии.
>Я никакого паттерна не усваивал. Я просто критически отношусь к догмам.
Золотые слова! Подписываюсь на 100%. Предлагаю немедленно отказаться от догм, связанных с этой самой сериализацией. Например, от идеи сериализации и десериализации для клонирования.
>А ты как раз держишься за них со страшной силой. "У строки нету длины", "у матрицы длина должна быть в начале"
М-да, ну и догма. У матрицы длина должна быть в начале... И анафема всем , кто с этим не согласен. Так, видимо, в твоем представлении мое мнение выглядит.
Я как раз наоборот против догм. Почти любых. Я готов сериализовать, если найду удобным, и не сериализовать, если мне не подходит. Устраивать прогулки в файле вдоль и поперек и писать туда строго последовательно. Строго соблюдать канонические формы БД и нарушать их , начиная с самой первой, если посчитаю это нужным. И т.д. И вообще догм для меня нет — практически нет. Более того, выскажу здесь мое любимое высказывание
При решении многих задач (кроме самых тривиальных) вполне может возникнуть ситуация, когда наилучшим является решение, противоречащее большинству общепринятых норм и правил.
Извини, но комментировать и приводить примеры не буду. Честно говоря, мне эта дискуссия уже надоела.
>... Мне очень забавно наблюдать за твоими попытками загнать меня в угол и высосать из пальца аргументы в пользу утверждений, которые ты просто никогда не проверял.
Да уж в угол-то ты сам себя загнал своим ляпом насчет диагонализации матрицы. Мне только оставалось сей факт зафиксировать.
PD>>Ты знаешь, что есть такая сериализация, и теперь упорно пытаешься ее сунуть и туда, где она годится как нельзя лучше, и туда, где она — пришей кобыле хвост. S>Я все еще жду от тебя примера персистенса, для которого не годится сериализация.
А я тебе его привел, да только тебе он не понравился, вот ты и начал тень на плетень наводить насчет запросов. А для меня это — сохранение объекта. В форме, в которой мне удобно его будет потом читать. Я на этом алгоритме свою работу сделал и деньги за это получил. И крутится этот код на сотнях компьютеров, сотни тысяч образцов через него проходят. Вот и все. Хочешь — называй это запросами, хочешь — вопросами, хочешь — трансакциями, хочешь — еще как-то. Мне это попросту неинтересно.
Здравствуйте, VladD2, Вы писали:
VD>Еще раз извиняюсь, если задел. Постораюсь это не делать. Но и ты не принимай указание на твои ошибки за оскорбление.
Ok.
VD>Последователная форма в данном случае означает "форма с которой легко манипулировать". Если говорить не псевдонаучным языком, а по простому. Сериализация — это превращение состояния графа объектов в некую простую структуру данных. Онятно, что некое бинарное дерево вряд ил можно назвать простой структурой. По этому в МФЦ или других фрэймворках под простой структурой понимают или массив байтов или поток. Делается это исключительно по той причине, что это самые примитивные абстракции в следствии чего с ними можно манипулировать наиболее абстрано. Их можно передавать по сети, записывать в файлы, шифровать, пихать в БД...
Не пойдет. "форма с которой легко манипулировать" — слишком неконкретно. Для меня массив — форма с которой достаточно легко манипулировать. Поэтому выкладывание графа в массив есть перевод его именно в такую форму. Но это не сериализация.
Да и вообще — что значит легко ? Тебе легко, мне не очень...
VD>Но еще раз замечу, что сериализация не подразумевает того, что она должна делать последовательно.
В такой постановке полностью согласен. В сущности, все можно проще сформулировать.
Дайте мне в сериализационных классах, методах, функциях и т.д. и т.п. возможность произвольно перемещаться по потоку — я немедленно отказываюсь от всех своих возражений, потому что исчезает предмет спора, а остается лишь вопрос — что лучше — fseek или то, что там будет предложено. Об этом спорить не стоит
В MFC этого нет. В .net — раскажи, как это делать, если там это есть.
>Важно, что в итоге ты получашь поток или массив. Формировать же его можно по разному. И это уже вопрос реализации и эффектиности. Причем не нужно смешивать вопрос обстракции (поток/массив) с вопросами эффективности (того как пихать данные в эти самые массивы/потоки).
Нужно. См. мои другие пистма к тебе, не хочу повторяться.
VD>Именно. Но еще раз. Не надо применять термин "выкладывал". Записывал будет понятнее и непротиворичивее.
Принимается. Записал тем способом, который нашел нужным. С последовательным , прямым, индексно-последовательным или еще каким методом достпа к хранилищу. Если это определение устраивает — снимаю все возражения, только объясни как это сделать с помощью сериализации уже в смысле [Serializable] и т.д. В общем, код в студию.
VD>В MFC сделано решение позволяющее уростить сериализацию. И ты волен его не использовать. MFC просто пытается облегчить тебе жизнь. Я откроевнно говоря уже не помню всех тонкостей, но если не ошибаюсь ты можешь перехватить процесс сериализации и сделать его вручную.
Да. Что и делаю обычно.
VD>Опять же то, что MFC требует чтобы в конце процесса получилась та самая последовательная форма не подразумевает что обязательно нужно последовательно формировать эти данные. Ты можешь сформировать их в буфере и отдать уже результат.
Это означает дополнительную память, без которой я могу обойтись. Во имя чего я должен ее запрашивать — не знаю. И если я так поступлю — зачем мне сериализация ? Коль все у меня уже в буфере — один fwrite, и все на диске.
VD>Так что опять констатируем, что MFC предлагает интерфейс (абстракцию) и одну из форм реализации, а ты обижашся на MFC говоря, что интерфейс тебе не нравится, так как он не позволяет пременять алгоритм который тебе нравится.
Именно. Сериализация в MFC идет через CArchive, в котором позиционирования нет.
>В этом и заключается ошибка, на мой взгляд. MFC не подразумевает того, что запись этого самого состояния нужно делать именно через него.
Подразумевает. Применение сериализации увязано с архитектурой документ-вид. Документ сериализуется, это рекомендуемый подход. Убирая сериализацию, я вынужден многое делать сам. Фактически я отказываюсь от части возможностей MFC.
>Более того, создатели MFC скоре всего и рассчитывали на то, что если кому-то потребуется более сложный механизм, то он просто сформирует данные в отдельном буфере и уже из него отдаст MFC данные через предопределенный ею интерфейс.
Нет. Создтели MFC просто заложили туда механизм отказа от сериализации для таких личностей. Перехватываем OnOpenDocument — OnSaveDocument и все дела.
VD>>>Естественно! Вообще многое не обязательно. Например, не обязательно выходить на улицу в одежде или при размышлениях пользоваться логикой.
PD>>Глупо. Аргументы подобного уровня заставляют только сомневаться в правоте аргументирующего.
VD>Это называется сарказм. Ты сомневашся в совершенно очевидных, на мой взгляд, вещах. Я не говорю тебе об этом открыто, а даю понять это приведением абсурдных аналогий. Так что могу посоветовать только по чаще включать юмор и улыбаться.
За совет спасибо . Просто хочу заметить — аргументы подобного рода люди употребляют, когда им других не хватает. Не надо действовать в споре на эмоции, мы не на митинге.
PD>>Ох, надоело мне это упоминание больших проектов. Откуда тебе знать, в каких проектах я участвовал, что ты все время пытаешься мне это тыкать ? Проекта с суммарным размером исходников в 10 Мб хватит?
VD>Я сужу по высказваниям. И, кстати, если ты заметил не говори тебе, что ты не участвовал в больших проектах. Просто твое не верное, на мой взгляд, отношение к абстракциям явно не способствует при работе над большими проектами.
Ну не способствует, так не надо. Лишь бы работало.
PD>>Ну спасибо, просветил. Без тебя я про структурное программирование и ООП так и не узнал бы .
VD>Про ООП узнать мало. Еще нужно вжиться в него.
Слушай, хватит. Я про ООП узнал еще во время Turbo Pascal 5.5. И все этапы его помню, могу хоть сейчас историю написать.
VD> Не прийми следующие слова за оскобление, но я четко вижу, что ты плохо вжился в ООП. Твое отношение к абстракциям крайне не верное. Ты смотришь на них сквозь призму реализации, а это не верно!
Нет, оскорбительного здесь ничего не вижу. А с посылкой — не согласен. Архитектор строит дома, думая об абстракциях (колонны, фундамент, фасад, крыша). Но если он при этом не учитывает свойств бетона или кирпича — здание рушится.
VD>Если ты вместо того, чтобы пользоваться готовыми абстракциями будешь создавать собственные аргументируя это тем, что "так быстрее", то точно создашь проблемы себе и окружающим. Что же до работы на сотнях компьюетров, то мои ранние программы работали на тысячах компьютеров, но я сказал бы, что написаны они били припохабно. Так что тут зависимости нет. Работать можно заставить даже самый бездарный код. Был бы напор и желением. А вот создать код который не только что-то делает, но и легко модифицируется и заменяется на другой елси это потребуется — это куда более сожная задача. И в больших проектах она востребована как никогда. От того я и упоминаю бльшие проекты.
Либо да, либо нет. От ситуации зависит.
Код, который я писал, никогда и нигде не будет использован для других целей. В этом можно быть уверенным на 200% — ни одному другому заказчику в мире он не понадобится, потому что такого заказчика в мире не существует и не может появиться. Более того, и предметная область измениться не может (если не произойдет светопреставления по крайней мере в течение этого столетия. Извини, что говорю так обще, но поверь, что это так. Так что вопрос об адаптации кода не возникает вообще.
А вот вопрос о его быстродействии — принципиально важен. Если бы он работал в 3 раза медленнее — меня бы из этого проекта выкинули бы. Потому что такое у них и без меня было, я не с самого начала в этот проект вошел.
PD>>Да уж, действительно мелочи. будет ли в результате файл размером в 10 Кб или 10 Мб, будет ли это работать быстро или медленно — это все мелочи. Зато принципы будут соблюдены.
VD>Раскажи мне, плиз, как связаны размеры файлов и скорость работы кода с тем, что интерфейс сериализации требует последовательной записи?
В огороде бузина, а в Киеве дядька. Мне не маловажно — каков размер будет у файла и как быстро это будет работать. Ты меня спрашиваешь — а как это связано с последовательной записью? Ответ банален — если есть механизм записать это последовательно при малом размере файла и при хорошей скорости , то надо его использовать. Если нет -использовать другие алгоритмы.
PD>>В письме к Sinclair я сформулировал конкретно задачу (с матрицей). Напиши свое решение, обсудим. Хватит обо общих принциах говорить, код в студию.
VD>Я не буду писать тебе кокретных решений. Я тебе просто попробую написать очень простой код и донести его смысл. Сериализацию можно представить как функцию: VD>
VD>Ты волен реализовать эту функцию как угодно. Единственное что ты не должен менять — это сигнатуру этой функции, так как — это интерфейс между тобой и остальным миром.
Чудненько. Расскажи, как в этой функции свободно передвигаться в этом Stream (кстати, я не понял, почему он на выходе — я его создать в функции должен, что ли ?) и все будет прекрасно. А потом расскажи, как это привязать к [Serializable], XYZFormatter и т.д.
VD>Все твои рассуждения связанные со скоростью и компактностью — это рассуждения о тех трех точках. Ты же пыташся начать рассуждать о сигнатуре функции. Вот в этом и заключается ошибка.
Ну вот, еще лучше. Я о сигнатуре в этом треде впервые от тебя услышал десятью строками раньше.
VD>Пойми, что твоя функция универсальна пока она соблюдает этот интерфейс. И это очень важно!
Влад, ну хватит, сил же нет. Что ты мне банальные вещи объясняешь! Ты еще бы про типы указателей в С++ написал бы или про сигнатуры делегатов!
VD>Если абстрогироваться от обит и поптыаться проанилизировать сви ошибки, то ты увидишь, что умение мыслить абстракциями как раз и подразумевает при размышлениях возможность отрешитья от эффективности реализации. Тебе достаточно общей характеристики для твоих размышлений. Следующим шагом будет умение выбрать компромис между универсальностью и эффективностью. Ты явно (опять же на мой взгляд) слишком сильно зациклен на эффективности от того злишся на абстракции. А это не верно! Ну, не виноваты абстракции ни в чем.
Хорошо, Влад, а объясни, в чем я неправ. Я ведь не против того, что нужны эти абстракции. Но почему я не прав, когда все же при этом думаю о свойствах кирпича, из которого эти колонны строить буду. Ведь не воздушный замок же я строю! Почему я должен от свойств материала отрешаться ? Ведь рухнуть же может здание, не выдержат они и будет ЧП. А абстрактно — колонны вещь замечательная. Красиво и приятно. А потом выяснится вдруг — крышу не держат. Примеры напомнить ?
PD>>Для тебя — есть объект, надо сохранить, выведем поток. Все ясно. PD>>Для меня — есть объект, надо сохранить. Можно выести в поток, а это хорошо будет ? Размер файла ? Скорость ? Хорошо ? Тогда ладно. Нет ? А что другое можно предложить ? И т.д.
VD>Во-вот. Для меня есть здача. Далее я пытаюсь выбрать паттерны для ее решения и абстракции для представления сущьностей учавствующих в этом решении. Если задача сохранить состояние объекта в файл и загрузить его в последствии, и при этом нет нужны в анализе этого состояния, то я выберу паттерн "Сериализация". Если я выбрал это паттерн, то совершенно логично, что абстракция "Состояние" подразумеваемая этим паттерном будет поток или массив байтов. Так же совершенно логично, что сам процесс сериализации будет представлен функцией параметром которой является сериализуемый объект, а возвращаемым значением этотм самый потк (короче как в примере выше). Выбор потока обуславливается тем, что это самая универсальная абстракция из пригодных для представления состояния.
Со всем согласен.
VD>Далее я задумаюсь над реализацией той самой функции. Вот тут я как и ты задумаюсь над тем как более эффективно сериализовать состояние графа объектов. И о том, что мне важнее универсальность, скорость, размер сериализованного представления или какое-то сочетание этих аспектов. Например, если размер и скорость мне не очень важны, то я могу воспользоваться не очень эффективным встроенным механизмом сериализации в дотнете. Если мне важен размер, то я могу реализовать автоматическую сериализацния на без рефлексии. А если мне нужна и скорость, и компактность результата, то скорее всего я создам метапрограмму генерирующую код для некоторого списка классов.
Тоже со всем согласен. А теперь добавлю.
А если в ходе этого анализа я выясню, что эффективной паттерна "Сериализация". реализации в данном случае не существует, то я начну все сначала. А именно
Для меня есть здача. Далее я пытаюсь выбрать паттерны для ее решения и абстракции для представления сущьностей учавствующих в этом решении. Если задача сохранить состояние объекта в файл и загрузить его в последствии, и при этом нет нужны в анализе этого состояния, то я выберу паттерн "Сериализация". Но поскольку оказалось, что эффективной реализации сериализации не имеется для данной задачи, то я прибегну к паттерну "Файл произвольного доступа" (или индексно-последовательный файл, или еще что, не важно). Не потому, что я против паттерна "Сериализация", а потому что мне не удалось найти эффективной реализации его в условиях данной конкретной задачи. Ну и т.д.
VD>Важно другое. У нас в корне отличается стадия анализа. Ты уже на самых ранних стадиях размышлений сваливашся на обсуждение деталией, то есть на очень низкий уровень абстракции. Я же пытаюсь этго не допустить. Только и всего.
Нет. Я просто одновременно работаю на обоих уровнях. И на высоком (шаблоны, паттерны, компоненты, абстракции) , и на низком (реализация, блоки памяти, быстродействие и т.д.). Не помню, кто именно, кто-то из гуру программирования определил его как умени легко переключаться от верхнего уровня к нижнему и обратно.
А вообще у меня такое впечатление (может, я и сам виноват, что у тебя такое впечатление сложмлось), что ты обо мне просто неверного мнения. Я не против размышлений на верхнем уровне. И декомпозируя задачу, я именно так и мыслю — вот здесь вроде стек, тут очередь, здесь дерево должно быть. Но при этом каждый раз задаю себе вопрос — а это как будет внизу выглядеть ? Это эффективно будет ? Или есть лучшее решение ?
А ты — не хочешь (это опять-таки мое мнение, как оно сложилось о тебе). Ты готов на верхнем уровне о деталях не думать. А потом, конечно, на нижний уровень спустишься, но при этом верхний ты уже разработал, при этом не думая о нижнем.
Вот ответь на вопрос прямо. Выбрал ты паттерн сериализация. Продумал все. Написал код. Говорят — работает медленно. Пытаешься улучшить — не получается. Что делать будешь ?
Заметь, я тебя не спрашиваю, почему медленно. Не обсуждается это. Просто прими как факт — медленно, заказчика не устраивает. И именно в том месте, где сериализация твоя.
PD>>А если ее нельзя реализовать в данной ситуации эффективно ? Нельзя, и все. А неэффективно — не принимается. Ваше решение ?
VD>Значит имеет место один из двух фактов: VD>1. Ты недостаточно подготовлен для грамотного решения задачи. VD>2. Эта абстракция неподходит и надо искать другую.
Ага! Прекрасно!
А откуда тебе это стало известно ? Что не подходит ?
Ты ведь утверждаешь, что об абстракции можно говорить, не вдаваясь в детали реализации. Так до того, как код написан и быстродействие его померяно, откуда тебе знать, годится она или нет ?
PD>>Кстати, разъясни фразу "приблизительно в 10 раз менее эффективны, чем аналогичные исползующие прямую работу с БД". Ты утверждаешь, что у меня в 10 раз больше данных выбирается, или в 10 раз больше модификаций делается, или что ? Если это — можешь быть уверен, что это далеко не так, ничего лишнего там выбираться не будет.
VD>Под эффективностью тут имеется в виду скорость работы. O/RMapper-ы в принципе не эффективны. Пока что никому не удалось создать реализацию O/R Mapping-а которая была бы соизмерима со скоростью добротно написанного приложения работающего с БД по сдерствам запросов.
Поточнее , пожалуйста. Если ты имеешь в виду, что маппер не слишком эффективно из строки БД формирует экземпляр класса (в ОП), то я с этим согласен. Там на каждом шагу Reflection, распихивание полей из массива и т.д. Я бы специализированно намного проще написал. Но это в ОП. А что касается SQL, то тут все под контролем. Все, что он делает, я в окне отладки вижу. И никакие SELECT я не допущу, если не признаю их нужными, и никакие лишние поля — тоже.
PD>>Вот тебе абстракция — линейный список с возможностью доступа по индексу к имеющимся элементам? Годится абстракция?
VD>Годится.
PD>>А теперь ответь — можно ли использовать эту абстракцию для хранения данных, если
PD>>a)
PD>>1) количество элементов очень велико VD>Не влияет на выбор абстракции. PD>>2) операции вставки/удаления в начало производятся очень часто VD>Не влияет на выбор абстракции. PD>>3) операции доступа по индексу производятся очень редко VD>Единственный важный факт из перечисленных. PD>>4) скорость работы критична VD>Не влияет на выбор абстракции.
VD>Ответ будет один — да, можно.
PD>>б)
PD>>1) количество элементов очень велико VD>Единственный важный факт из перечисленных. PD>>2) операции вставки/удаления в начало производятся очень редко VD>Единственный важный факт из перечисленных. PD>>3) операции доступа по индексу производятся очень часто VD>Единственный важный факт из перечисленных. PD>>4) скорость работы критична VD>Единственный важный факт из перечисленных.
VD>Тоже можно.
PD>>Непременное условие — о реализации ты ничего не знаешь, как ты и хотел. Иными словами, после того, как ты ответишь на оба вопроса, я тебе сообщу, какая именно реализация используется в библиотеке, которую ты должен использовать.
VD>А мне не нужно сообщать. Я выбрал абстракцию. Твои условия ей не противоречат. А вот реализацию абстракции я выбиру сам исходя из тех самых критериев которые ты перечислил. Причем критерии вроде "количество элементов очень велико" для меня явлюятся пустым звуком. "Очень велико" может означать разные вещи для разных людей или разных уловий.
PD>>И просьба не отвечать — дескать, если меня не устроит эта реализация, я другую сделаю. Нет у тебя такого права.
VD>А это условие чтобы прикольнее было?
Нет. В этом-то и дело. Ты должен использовать ArrayList (теперь я тебе сообщаю). Он безусловно является реализацией той самйо абстракции. Число элементов — порядка 10 тысяч, доступ по индексу очень редко, вставка (Insert, а не Add) и удаление очень часто.
Как со скоростью работы будет ?
VD>Когда это? Я всего лишь отделил выбор абстракции, от выбора ее реализации. Я определился с тем, что для меня приемлема конкретная абстракция (список с произвольным доступом), и теперь могу определиться с конретной реализацей. Причем реализацию я могу и заменить в последствии.
Ну что же, прекрасно. Пусть даже так.
Итак, и для a) и для b) ты признал, что абстракция годится. Хорошо. а если у тебя в программе одновременно и a), и b) ? В одной части a), в другой b) ? А реализацию, ладно, выбирай сам, но только одну.
PD>>Для того, чтобы самолет летал быстрее, чем паровоз ездит
VD>Полетят у тебя они оба в одном направлении с такими подходами... под откос.
Опять неумно. Влад, пойми наконец — это не аргумент. Когда аргументов иных нет — начинают на такие переходить.
Ну скажи на милость, почему я должен к этой фразе серьезно относиться? Ну добро бы я только начинал. А то ведь участвовал в довольно серьезных проектах. И ничего под откос не летело, работает себе. А тут приходишь ты и говоришь — при таком подходе обязательно под откос полетит (самолет...). И что я подумать должен ? На одной чашке весов — то, что я сделал. На другой — заявление человека, который меня и знать-то не знает, а такие вещт с апломбом говорит. Как ты думаешь, какой вывод я должен сделать ? ИМХО только один — не обращать на его слова внимания. Пусть себе говорит, что хочет, а то, что я сделал, у меня не отнимешь, и гордиться этим у меня основания есть
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В MFC этого нет. В .net — раскажи, как это делать, если там это есть.
Вся кастомная сериализация в .NET в итоге сводится к классу SerializationInfo. Соотв. заполнять ты ее можешь любым алгоритмом. Ползанья по потоку там, естественно, нету, поскольку основная задача штатной сериализации — передача информации между доменами (процессами, машинами), а там возможности позиционирования нет.
VD>>Про ООП узнать мало. Еще нужно вжиться в него.
PD>Слушай, хватит. Я про ООП узнал еще во время Turbo Pascal 5.5.
Я тоже. И что?
PD>А вот вопрос о его быстродействии — принципиально важен. Если бы он работал в 3 раза медленнее — меня бы из этого проекта выкинули бы. Потому что такое у них и без меня было, я не с самого начала в этот проект вошел.
То, что ты описал называется оптимизацией. Которая почти всегда ухудшает структуру программы. Но оптимизации делают обычно, когда точно известны узкие места. Делать ее заранее и везде — прямой путь к убийству мало мальски крупного проекта. Именно об этом и пытается тебе сказать Влад.
PD>Хорошо, Влад, а объясни, в чем я неправ. Я ведь не против того, что нужны эти абстракции. Но почему я не прав, когда все же при этом думаю о свойствах кирпича, из которого эти колонны строить буду.
Потому что мозги не резиновые. Если ты будешь думать о свойствах каждого из сотни тысяч кирпичей в здании, то ничего путного в плане общей архитектуры ты физически выдумать не сможешь. Это, собственно, было известно сто лет назад. И тогда же придумали единственный до сих пор способ с этим бороться — абстракции. Причем, что характерно, единственная абстракция обычно спасает ненадолго, поэтому вокруг абстракций приходится делать более высокоуровневые абстракции, вокруг них еще более высокоуровневые. Со временем сложность программ растет, растет и количество слоев абстракций (зависимость где то O(lg(7-8) N), где N — мера сложности системы).
Теперь от лирики перейдем к конкретике. Примеряя твои слова на вышесказанное у меня возникает масса вопросов. Вот некоторые из них:
1) Предлагая одновременно с абстракциями думать о реализации, ты увеличиваешь количество сущностей на одном уровне. Поскольку мозги, как я уже писал, не резиновые, а абстракции обычно делают в притык по сложности понимания (потому что вводят не просто так, а в тот момент, когда без них уже нельзя), возникает вопрос — как количество сущностей сократить до приемлемого для человека? Если мы будем сужать абстракцию, то придется поверх наращивать еще один абстрактный слой, что совсем не здорово, так как в итоге увеличивает тот самый оверхед, с которым ты борешься. Проще говоря — ты ускорил свой участок за счет сужения абстракции, но код, который использует твой участок, вынужденно усложнится и станет медленнее. Т.е. проблема никуда не делась, она просто перетекла в другое место.
2) В современном программировании, даже в том стиле, который ты предлагаешь, мы всегда имеем слои абстракции и сверху, и, что совсем не удивительно, снизу. Возвращаясь к твоему примеру — файл конечно существенно более узкое понятие, нежели поток, но тем не менее это тоже абстракция и даже не самая последняя в ряду. Теперь собственно вопрос — в какой момент нам следует прекратить думать о реализации нижележащих абстракций? Почему я, при создании сериализации, должен думать о файле, но не должен думать о кластерной структуре ФС? Или должен. Тогда когда не должен? Об абстрактной модели контроллера IDE должен?
PD> Ведь не воздушный замок же я строю! Почему я должен от свойств материала отрешаться ? Ведь рухнуть же может здание, не выдержат они и будет ЧП. А абстрактно — колонны вещь замечательная. Красиво и приятно. А потом выяснится вдруг — крышу не держат. Примеры напомнить ?
Я тебя умоляю — не стоит делать далеко идущие выводы из аналогий. Строительство это далеко не то же самое, что создание программ и тому есть масса причин.
PD>А если в ходе этого анализа я выясню, что эффективной паттерна "Сериализация". реализации в данном случае не существует, то я начну все сначала.
Это нормально. Называется рефакторинг. Ничего страшного в нем нет.
PD>Нет. Я просто одновременно работаю на обоих уровнях.
Знаешь поговорку о погоне за двумя зайцами?
PD>Ты ведь утверждаешь, что об абстракции можно говорить, не вдаваясь в детали реализации. Так до того, как код написан и быстродействие его померяно, откуда тебе знать, годится она или нет ?
Золотые слова. Этого не знает Влад. Более того — этого и ты не знаешь.
PD>Поточнее , пожалуйста. Если ты имеешь в виду, что маппер не слишком эффективно из строки БД формирует экземпляр класса (в ОП), то я с этим согласен. Там на каждом шагу Reflection, распихивание полей из массива и т.д.
Это мелочи. Там проблемы логического плана. Впрочем, попроси об этом рассказать Синклера, у него хорошо получается.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>Ты уж извини, но ты сам начал. Эта дисскуссия твоими оппонентами велась корректно, на примерах, фактах и логических построениях.
Позволю себе заметить, что мое участие в этой дискуссии ограничилось шутливой заметкой от 3.02
после чего я на протяжении 6 дней в ней ровно никакого участия не принимал вообще, так как и не собирался. Но когда Владу захотелось через неделю поставить меня на место
Здравствуйте, AndrewVK, Вы писали:
AVK>Тебе демагогологический анализ твоих сообщений устроить или сам справишся? Если первое — мне не сложно.
Ввиду того, что мой ответ и продолжение этой дискуссии с тобой не нуждается в том, чтобы это стало всеобщим достоянием, ответ отправлен по e-mail на адрес в твоих "Личных".
Продолжаю. То, на что уже ответил — выпущено.
AVK>>>Но я выбираю алгоритмы работы с ней. Например на FAT поиск файла это очень дорого, а на NTFS есть индексы и поиск значительно дешевле. Какое грамотное решение ты видишь в подобной ситуации? Наплевать на то, что в случае NTFS мы получаем оверхед и городить свои индексы? Или сделать решение, тормозящее на FAT?
PD>>Не знаю.
AVK>А кто знает?
PD>> От задачи зависит и от требований.
AVK>Ну задачу можно придумать. Пусть это будет кеш прокси-сервера.
Ничего себе заявление!. Я говорю — От задачи зависит и от требований. Мне в ответ — ну вот тебе задача. Без указания требований к железу, без указания требованйи к софту, без подробной спецификации — на тебе задачу, иди и скажи, как решать будешь. У Вас что, принятно так техзадания выдавать? Сделайте мне прокси-сервер — и радостный девелопер отправляется его делать, не поинтересовавшись даже, для каких целей он нужен, не говоря уж о прочем. М-да...
Вот когда подробные спецификации будут — тогда и поговорим. Может, и FAT сгодится. Может, только NTFS. А может, я вообще просто один файл заведу и в нем свою собственную псевдо-ФС сделаю. Как, к примеру, kerio proxy 4.2 делает (с более поздними версиями не работал, не знаю как там). Потому что FAT — поиск последовательный,а это существенно, NTFS — оверхед на журналирование. Думать надо.
PD>> Если это критично и можно потребовать, чтобы FAT не было — это одно.
AVK>Помнится ты в свое время утверждал что эффективность в любом случае критична. Впрочем ладно. На этот вопрос я ответить не могу — может критично, а может и нет, пока не не попробуешь, не узнаешь.
Узнаешь. Вполне узнаешь. Мне по крайней мере это удавалось.
PD>>Еще раз — я не обсуждаю решения, пока не ясна задача.
AVK>А она не может быть ясна на 100% в начале разработки, это мы чуть выше вроде как уяснили.
На 100% — не может. Но это не означает, что нельзя оценить то, что можно.
Кстати, вот тебе вопрос как раз по твоему примеру, прокси. Ты мне тут много и упорно доказывал, что думать о реализации означает плодить сущности, а мозг человека не в состоянии охватить слишком многое. Вполне разумная мысль, не могу не согласиться. Только вот вопрос — а почему мозг одного человека ? И если все же одного — почему нельзя это по времени растянуть.
Как ты будешь прокси-сервер делать, и что там еще будет — опустим. Но вот есть подзадача — хранить получаемые файлы на диске, стирать их там периодически и т.д. Естественно, я полагаю, что спецификации разработаны, а значит, можно уже сейчас оценить предполагаемое количество файлов общее, в единицу времени, и т.д.
Так вот, вчера и позавчера я думал о прокси-сервере как таковом. На уровне самых высоких абстракций. А сегодня я запрещаю себе о нем думать. Сегодня задача такова — надо файлы хранить. Эффективно. Требования такие -то . Как делать будем ?
Или другому это поручи. Неплохо будет, если он FAT/NTFS хорошо знает, и вообще на этих делах собачку съел..
Он, кстати, даже и не обязан точно знать, зачем это нужно. Впрочем, лучше, если все же знает — две головы все же лучше.
Sinclair мне тут как-то популярно объяснял, что такое декомпозиция. Ликбез, так сказать, устроил. Вот я тебе эту декомпозицию и пересылаю. Декомпозируй (в данном случае подзадача выделяется элементарно) и отдай другому. Пусть продумает. Не только абстракцию "хранилище файлов", а и реализацию этого хранилища.
PD>> Я не верю в универсальные решения. Универсальные решения приводят к неэффективным программам. Я предпочитаю конкретику. Давайте задачу — будем обсуждать.
AVK>Ну задачу я тебе дал.
Я тебе тоже могу задачу дать. Напиши текстовый редактор. К завтрашнему дню. Берешься ?
PD>>Ты ведь , по сути, знаешь, что здесь утверждаешь ? Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает. Так получается ?
AVK>Ага.
PD>>Если да — ну тогда я просто не знаю, что сказать.
AVK>А хотелось бы услышать твое мнение. Что ты будешь в этой ситуации делать? Понадеешься на интуицию?
Интуиция — дело не такое уж плохое. В сущности, интуиция — это просто подсознательно оформленный предыдущий опыт. Я в самолетостроении ничего не понимаю, а поэтому никакой интуиции в этой области у меня нет. А когда я программное решение обдумываю — предыдущий опыт может вполне помочь, даже если в точности такую задачу я и не решал. Чувствую, что здесь будет узкое место. Потому как были уже. Может, и не помню, где были, но чувствую, что и здесь может быть. Подумать здесь хорошенько надо, прежде чем код писать.
Но вообще на вопрос — что буду делать — ответ простой. Я просто не согласен с исходной посылкой "Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает.". Ты согласен, я — нет. Так что я ничего в этой ситуации делать не должен.
PD>>Но чтобы уж так прямо утвержать — "только один способ существует, создать да посмотреть, что получилось" — ИМХО ни в одной области человеческой деятельности в Новое время никто такое не декларировал. Все же есть какая-то наука, а не только эмпирика.
AVK>Очень мало аналитической науки в программировании, исчезающе мало. Аналитическое моделирование СМО затыкается на сверхпримитивных системах. Академического курса теории СМО мне хватило, чтобы понять, что даже процессор с парой-тройкой уровней кеша аналитически практически не описывается. Что же говорить о реальных системах, чье поведение неизмеримо сложнее?
Серьезное заявление. В общем-то, не отмахнешься просто так. Ну что же...
Системы бывают сильно и слабосвязанные, как тебе известно, конечно. Если система очень сильно связанная, то да, трудно сказать, где что может возникнуть. Но далеко не всегда это так. И твой пример с прокси-сервером — как раз этому подтверждение. В конце концов, прокси — сервер или тестовая программа будет эти файлы генерировать — не все ли равно ? Подсистема почти автономна. И решалась эта задача не один раз — не ты же первый хранилище файлов создаешь при таких-то требованиях ? Так что оценить здесь можно, в крайнем случае тесты сделать — на их создание двух дней за глаза хватит. Продумать все, как следует. А не писать сразу первое, что вголову придет.
Вот, кстати, зачем в kerio они свой файл для прокси-кэша сделали ? Большая же работа — свою ФС (или что-то такое) внутри этого файла городить ? А все же сделали...
И хорошо ли будет, если по твоему пути пойти ? Сделаем проект, посмотрим как работает, если нужно будет — будем улучшать. Я правильно твою идею излагаю, не передергиваю ?
Ну вот и сделали. Файлы в каталоге диска храним. Прокси-сервер как таковой разрабатываем. Наконец готово в первом приближении. Тестируем — с сетью все OK, с файлами медленно, узкое звено оказалось здесь. Предлагаем FAT убрать(допустим, из-за нее проблемы) — заказчик не соглсаен. Что делать ?
И вот теперь приходим к выводу, что надо свою псевдо-ФС на отдельном файле делать. Положение — хуже губернаторского, до дедлайна две недели, все, в общем, готово, но из-за этого узкого звена новый огромный кусок появился, и его за 2 недели никак не сделать (допустим).
А что, нельзя было об этом за 3 месяца до срока узнать ? Подумать немного, интуицию привлечь да парочку тестов соорудить. И знали бы об этой проблеме, и решали бы ее параллельно...
PD>> Я может, в другом месте ошибусь — может. Может там оно медленно работать будет — может. Но означает ли это , что так уж ни о чем и думать не надо, когда массив здесь вставляешь ? Годится он сюда по своим методам/свойствам — годится. Берем. Неужели если я подумаю о том, что вставка в него очень дорогая по времени
AVK>Она не дорогая, она просто невозможна.
Почему невозможна ? Вполне возможна ? Создаем новый массив длины L+1, копируем в него элементы до нужной позиции, потом этот элемент, потом оставшиеся, исходный массив уничтожаем.
Более того, ты сейчас услышишь от меня (адепта эффективности) странное утверждение. Вполне возможно, что в определенной ситуации я именно это решение и выберу. При всей его неэффективности как будто. Потому что знаю — элементов в массиве две сотни, вставки производятся раз в 5 минут, доступ по индексу — 100000 раз в секунду. Начни я что-то иное придумывать — намного дороже обойдется.
AVK>Я делаю очень просто — выбираю минимальную абстракцию (например IList<T> или ICollection<T> или даже IEnumerable<T>). И мне совершенно пофигу сколько стоит вставка — массив в любом случае не должен меняться снаружи напрямую, поскольку отследить внутри это невозможно. Ну а внутри я всегда волен менять массив на что угодно другое, как только он станет неподходящим. Единственное для чего можно использовать в публичном интерфейсе массив напрямую — как контейнер для параметров или возвращаемого значения.
Хм... Ну а если в итоге окажется, что ни одной имплементации IList нет с нужным быстродействием ? К примеру, выяснится, что лучше всего для хранения HashTable использовать, это все же (условно) O(1) на вставку и на поиск, а там — не получается. Или дерево двоичное (допустим, IList не поддерживает). Тогда как , все переделывать ?
AVK>>>Ну вот тогда и не делай из них выводы. Единственное использование аналогий в споре, не являющееся демагогией, это применение их в качестве иллистраций каких то высказываний. Ты же сделал вывод, опираясь только на аналогию (здание рухнет, если не рассчитать прочность каждого кирпича -> программа рухнет, если не рассчитать прочность каждого кусочка кода).
PD>>Цитату , пожалуйста! Точную. Где я говорил, что программа рухнет.
AVK>
Хорошо, Влад, а объясни, в чем я неправ. Я ведь не против того, что нужны эти абстракции. Но почему я не прав, когда все же при этом думаю о свойствах кирпича, из которого эти колонны строить буду. Ведь не воздушный замок же я строю! Почему я должен от свойств материала отрешаться ? Ведь рухнуть же может здание, не выдержат они и будет ЧП. А абстрактно — колонны вещь замечательная. Красиво и приятно. А потом выяснится вдруг — крышу не держат. Примеры напомнить ?
AVK>Что ты этим хотел сказать?
Да то, что и в других места, когда говорил, что здание может рухнуть. Таких мест несколько. Про здание я говорил. А не про программу. Ясно же сказал в письме к тебе
PD>>>> Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
PD>>Вот это я говорил. Передергивать не надо. Некрасиво.
AVK>Все запротоколированно. Можешь открыть свое сообщение и посмотреть.
Именно. Прочти то, что я выделил жирным и не передергивай.
PD>Вот, кстати, зачем в kerio они свой файл для прокси-кэша сделали ? Большая же работа — свою ФС (или что-то такое) внутри этого файла городить ? А все же сделали... PD>И хорошо ли будет, если по твоему пути пойти ? Сделаем проект, посмотрим как работает, если нужно будет — будем улучшать. Я правильно твою идею излагаю, не передергиваю ? PD>Ну вот и сделали. Файлы в каталоге диска храним. Прокси-сервер как таковой разрабатываем. Наконец готово в первом приближении. Тестируем — с сетью все OK, с файлами медленно, узкое звено оказалось здесь. Предлагаем FAT убрать(допустим, из-за нее проблемы) — заказчик не соглсаен. Что делать ? PD>И вот теперь приходим к выводу, что надо свою псевдо-ФС на отдельном файле делать. Положение — хуже губернаторского, до дедлайна две недели, все, в общем, готово, но из-за этого узкого звена новый огромный кусок появился, и его за 2 недели никак не сделать (допустим). PD>А что, нельзя было об этом за 3 месяца до срока узнать ? Подумать немного, интуицию привлечь да парочку тестов соорудить. И знали бы об этой проблеме, и решали бы ее параллельно...
Вот конкретно это место мне совершенно непонятно. Отказавшись от своей ФС мы очень значительно сократили расходы. Поэтому я не вижу причины, по которой мы встрянем с производительностью за две недели до дедлайна. Получается, что если бы мы сразу стали делать собственную реализацию ФС, то она была бы готова на (три месяца — две недели) после дедлайна. А про решать параллельно — это сказки. Потому как ресурсы из воздуха не берутся. У нас там что, какой-то разработчик три месяца без дела болтался? Нет.
Да, если бы мы сразу заложили свою ФС, то скорее всего дедлайн автоматически был перенесен на три месяца, в команду был бы привлечен временный специалист по страничной организации файлового стораджа, етк, етк. А так мы рискуем напугать заказчика излишне оптимистичными заявлениями. Ну, это на самом деле камень в огород архитектора и ПМа. Потому, что в настоящем проджект плане есть такая секция "Risk Management". И если архитектор не идентифицировал вовремя риск того, что файлуха окажется недостаточно производительна, то ему и линейкой по пальцам. А если идентифицировал, но ПМ никакой mitigation туда не записал, то надо отправить ПМа на пару лет учить уставы (как известно, командир взвода — наиболее близкая специальность к "менеджеру среднего звена" в бывшем СССР, и выгодно отличается от новомодных курсов хорошей проработанностью программы).
Если проект развивается управляемым способом, то производительность ФС будет протестирована очень задолго до дедлайна. Потому что это почти ничего не стоит. И никто не станет вкладывать заранее деньги в оптимизацию того, что не было доказано в качестве узкого места. Слишком велик риск получить за две недели до дедлайна узкое место где-то еще. После того, как весь бюджет оптимизации съеден подчистую.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Подробную спецификацию это кодерам выдают и то не всегда. А ты, коль уж архитектор, работаешь не в тепличных, а вреальных условиях. Ты сам эту спецификацию создать должен.
Слушай, не надо, это уж совсем несерьезно. Персональный прокси-сервер, прокси для небольшой организации или тот прокси, через который, как утверждают, весь Китай в Интернет ходит (чтобы куда не надо не ходили) — это все же разные немного задачи ? Я что, должен сам додумывать ?
PD>>Вот когда подробные спецификации будут — тогда и поговорим.
AVK>Мда, плохой из тебя архитектор выходит.
Уж точно. Потому как категорически отказываюсь разрабатывать не то гоночную машину , не то КАМАЗ. Оба они автомобили, как понимаешь..
(А в скобках — тебе что именно надо — доказать неправильность моих идей или показать, что лично я — плохой архитектор ? Так ведь второе первое не доказывает. Даже если второе докажешь- первое от этого ни на йоту более доказанным не станет. Так что тебе здесь хочется ? Меня укольнуть ? Напрасно — на меня такие уколы не действуют . Тогда что ?)
AVK>Судя по тем преджположениям, что ты делал в форуме позволю себе не поверить.
Твое право. От этого ситуация не меняется. Софт работает, переделками не занимался, так что от твоей веры здесь ничего не зависит.
AVK>Помнишь я тебе вопросы задавал? Ты на большую часть не ответил. Попробуй, соотносясь с этим утверждением вопросы прочитать еще раз.
Ты же сам сказал — ответил, но не на все. А теперь, выходит, на большую часть не ответил. Ты уж в следующий раз уточняй. что ли — ответил на 43.5 % . А то я уж и не знаю, как отвечать.
PD>> И если все же одного — почему нельзя это по времени растянуть.
AVK>Потому что рынок.
А, ну вот так и говори. С этм возражением я согласен, я уже писал об этом. Только будем честными перед собой — мы заранее заявляем. что делать будем не лучшим образом. Тогда все, я свои возражения сниму.
Только не надо при этом хоть самого себя обманывать. Надо честно в этом признаться, и не возводить это в принцип, а признать, что в текущих условиях — иначе не можем.
Вот ответь прямо. Создали тебе идеальную ситуацию. Времени — сколько хочешь. Сроков нет. Специалистов — бери каких хочешь.
Так же будешь делать ?
PD>>Или другому это поручи. Неплохо будет, если он FAT/NTFS хорошо знает, и вообще на этих делах собачку съел..
AVK>Но мне то что делать? Я ведь должен архитектуру дальше делать. Я не могу оставить неспроектированным кусок целиком. Мне нужно ввести абстракцию, изолирующую меня от специфики хранения. Но, пользуясь твоей методикой, я этого сделать не могу, потому что она должна быть согласована с реализацией, а реализацию я не могу никак определить.
Ну неужто именно впрямь в именно этой задаче не можешь ? Ну попроси кого-нибудь сделать тесты. Добавляются файлы, столько-то в минуту, изменения нет, добавление в хвост есть, что там еще... Неужели сложно тест сделать без прокси-сервера, смоделировать эту ситуацию и посмотреть, какая нагрузка хотя бы по PerfMon ? И какое время отклика ? Там работы на 2 дня.
PD>>Sinclair мне тут как-то популярно объяснял, что такое декомпозиция. Ликбез, так сказать, устроил. Вот я тебе эту декомпозицию и пересылаю. Декомпозируй (в данном случае подзадача выделяется элементарно) и отдай другому.
AVK>При декомпозиции обычно учитывают только входные данные и структуру. Как делать декомпозицию с обязательным учетом реализации я не знаю.
Ну не знаешь, так не знаешь. Твои проблемы.
AVK>>>Ну задачу я тебе дал.
PD>>Я тебе тоже могу задачу дать. Напиши текстовый редактор. К завтрашнему дню. Берешься ?
AVK>Это называется передергивание.
Нет. Это столь же конкретная постановка задачи, ничем не лучше. К завтрашнему дню notepad написать вполне можно — MFC + CMYView::CEDitView почти весь он и есть (ну там поимк еще добавить). А вот Word — не возьмусь. И не к завтрашнему дню, а вообще не возьмусь.
AVK>Вот мы и пришли к моменту, который ты упорно пытаешься игнорировать — жесткая привязка абстракций к реализации ведет к сильносвязным системам,
Не ведет. Как ни реализуй модуль записи файлов в твоем прокси, от этого связность остальной части с этой компонентой не изменится. Хоть что там внутри этой компоненты будет.
>что, в свою очередь резко уменьшает предсказуемость такой системы и резко же усложняет ее дальнейшую модификацию.
Это почему ? На примере прокси, пожалуйста.
Ну а если уж на то пошло, то в моей работе (о которой у теяб такие сомнения) от меня как раз и требовали обеспечить доступ к данным. Абстракции — не требовали, предельно оптимальный доступ — да. И именно это я делал. Не слишком вдаваясь , зачем им тот или другой запрос нужен. А они тоже не очень вдавались в то, как я это сделаю, просто знали — сделаю все, что ни попросят.
Так мы и жили
Переход к слабосвязным системам снимает структурные проблемы, но ведет к снижению эфективности на стыках. Найти золотую середину — одна из сверхзадач проектирования архитектуры. Говорить сейчас о конкретном ее значении без конкретики конечно бессмысленно, но одно очевидно — чем больше у нас ресурсов, тем сильнее золотая середина смещается к слабосвязным решениям.
Именно. А слабосвязанные задачи предполагают декомпозицию до такого состояния, когда влияние связи намного меньше, чем самих компонент. В данном случае — производительность прокси при грамотной реализации может быть сделана такой, что эффект хранения данных на диске незначителен по сравнению с пропускной способностью по сети. Или наоборот.
AVK>Что же касается того, как эту середину выбрать, то ответ тоже уже был дан. Нужно проектировать максимально слабосвязное решение,
100% согласен.
>а потом, по мере необходимости, мигрировать в узких местах к решениям более связным.
А надо ли ? Если слабосвязанное решение оптимально по своим компонентам, а эффект от связи на порядок ниже чем от компонент, то оптимизировать надо ту компоненту, которая есть лимитирующая стадия процесса. А не связь. А лучше ее выявить на стадии проектирования и учесть. Реализацию ее.
>Здесь, опять же, замечу, что с увеличением количества ресурсов узкие места совсем не обязательно остануться там же, где и были.
Ну вообще-то, конечно, может быть. А реально, ответь на примере твоего прокси — если , скажем, файловая часть будет сделана наилучшим образом, из-за чего вдруг возникнет узкое место на связи этой подсистемы с остальной частью ? И что надо сделать, если она возникнет ? Ухудшить эту часть ?
>Т.е., перефразируя, оптимизации по потреблению ресурсов сильно зависят от конкретного количества и соотношения этих ресурсовю
Ну да, конечно. Поэтому-то я и возмутился, когда ты мне предложил абстрактный проки спроектировать.
AVK>А зачем делать тесты, если можно сразу начать проектировать систему? Если, как ты утверждаешь, у тебя очень хорошая интуиция, то и переделывать потом ничего не придется.
Неразумно. Моя интуиция — как я уже сказал, подсознательный прошлый опыт. Если он есть и я чувствую, что здесь можно ожидать (по прошлому опыту знаю) — тесты не нужны, конечно. Ну доведем до логического конца -я уже такое писал, для другой задачи, зачем мне тесты, когда я и так знаю, чего здесь можно ждать. Но в реальности это не всегда так, так что интуиция интуицией, а попробовать не мешает. Для того, чтобы интуиция не подвела.
PD>>Вот, кстати, зачем в kerio они свой файл для прокси-кэша сделали ? Большая же работа — свою ФС (или что-то такое) внутри этого файла городить ? А все же сделали...
AVK>А оно там было с первых версий?
Понятия не имею.
PD>>И вот теперь приходим к выводу, что надо свою псевдо-ФС на отдельном файле делать. Положение — хуже губернаторского, до дедлайна две недели, все, в общем, готово, но из-за этого узкого звена новый огромный кусок появился, и его за 2 недели никак не сделать (допустим).
AVK>Устанавливать жесткие дедлайны до того, как будет получен работающий прототип — признак недалекого ума РМов.
М-да... Заказчик-то срок установил.
PD>>А что, нельзя было об этом за 3 месяца до срока узнать ? Подумать немного, интуицию привлечь да парочку тестов соорудить.
AVK>Еще раз — чем тесты лучше прототипа?
1. Очень дешевы. Годится или нет FAT/NTFS — через 2 дня будешь знать. Прототип когда еще готов будет...
2. Нет прочей информации. Не просто слабосвязано — нульсвязано. В чистом виде. В идеальных условиях. И уж если в идеальных условиях нет нужной производительности — пиши пропало, в реальной обстановке только хуже будет.
AVK>>>Она не дорогая, она просто невозможна.
PD>>Почему невозможна ?
AVK>Потому.
PD>> Вполне возможна ? Создаем новый массив длины L+1, копируем в него элементы до нужной позиции, потом этот элемент, потом оставшиеся, исходный массив уничтожаем.
AVK>Массив сам такое не умеет. То, что ты написал называется список на массивах. И это тоже не абстракция. Речь же идет о выборе абстракций.
Хм, не понял
int * p = new int[99];
// fill p
int i,x = 1000;
int * p1 = new int[100];
for(i = 0; i < 24; i++)
p1[i] = p[i]; // я бы, конечно, memcpy реально употребил, это только для наглядности
p[24] = x;
for(i = 24; i < 99; i++)
p1[i+1] = p[i];
delete p;
p=p1;
Вот и все. Кто тут чего умеет и не умеет — бог знает. Где тут список — решительно не понимаю. Если можешь — объясни. Только без схоластики, пожалуйста, насчет ООП и прочего. Просто объясни.
PD>> К примеру, выяснится, что лучше всего для хранения HashTable использовать, это все же (условно) O(1) на вставку и на поиск, а там — не получается.
AVK>Я тебе уже кажется говорил — хеш-таблица и список это разные вещи, они не взаимозаменяемы.
А мне что в лоб, что по лбу. Мне данные хранить надо. Доступ к ним — хорошо, если бы по индексу, это удобнее всего. Но если по индексу не удастся найти нужной реализации — ладно, по ключу доступ тоже сойдет Мне на высокие материи наплевать, мне не теория нужна, что там заменяемо, а что нет. Мне — что делать, ответь ?
PD>> Или дерево двоичное (допустим, IList не поддерживает). Тогда как , все переделывать ?
AVK>Писать свою реализацию IList. А в чем проблема?
Ну и ну! Заложили туда IList, а выяснилось, что ни одной приличной реализации нет. Писать свою будем. А рядом хеш-таблица и дерево , оба вполне годятся, а мы говорим — ну уж нет, заложили мы IList, так будет IList. Свою реализацию его напишем (еще вопрос — будет ли лучше), время на это потратим, зато IList останется. Во имя высших принципов.И все из-за того, что на стадии проектирования не задумались — а есть ли вообще у IList реализация, где ни для каких операций нет O(N). А если нет — стоит ли самому ее изобретать или же можно другие кандидаты поискать.
PD>>Да то, что и в других места, когда говорил, что здание может рухнуть. Таких мест несколько. Про здание я говорил. А не про программу. Ясно же сказал в письме к тебе
AVK>Офигеть. Так у нас тут форум по строительству зданий оказывается. А я то думал ... Ну тогда как нибудь без меня, я в кирпичах не специалист, за всю свою жизнь только один дом и построил.
Действительно офигеть можно. Человеку приводишь аналогию, а он ее буквально понимает. Ладно, придется впредь с тобой аналогиями не пользоваться.
Там еще одно письмо вроде от тебя лежит — извини, не отвечу. Да и вообще продолжу эту тему, если будет время. Не уверен.
А может, и не надо продолжать. Позиции сторон ясны, согласовать их в главном невозможно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ни один. Проект сделан надолго, изменения в него вносить не придется. По причине того, что предметная область не будет изменена в течение ближайших десятилетий, да и вообще в обозримом будущем. Если не будет светопреставления. Никаких расширений там быть не может по определению — за полной их ненадобностью. Поверь, это действительно так.
Если в данном проекте никакой саппорт кода действительно не предусматривается, расскажи о другом проекте
PD>Да, конечно, ситуация нетипичная, я понимаю. Но на тему поддержки и расширения кода я сейчас высказываться не буду — не готов. Будет время — трону и эту священную корову за вымя . В отдельном топике.
мы все уже трепещем
>>Неплохо бы также узнать их мнение о твоем коде.
PD>Ну если уж тебя это так интересует... Специально для тебя разыскал в почте.
PD>Pavel,
PD>I'd just like to thank you for all your effort this year. You have made PD>a major contribution to the success of the project so far. I hope PD>you will continue to enjoy the challenges of the project in 2003. Although you PD>are so far away you are always included in our thoughts and PD>conversations. We all appreciate the effort you have made.
ну я ведь просил отзывы других программистов, а не заказчика. А это — всего лишь стандартная отписка. Не сомневаюсь, что она у них в шаблоне сохранена, дабы рассылать разработчикам, которые не облажались слишком уж явно. Доброе слово — оно ведь и кошке приятно
Я надеюсь, ты не принял это всё за чистую монету?
Здравствуйте, Дарней, Вы писали:
Д>мы все уже трепещем Д>Я надеюсь, ты не принял это всё за чистую монету?
Угу. У меня таких признаний — полный архив. Они причем совершенно искренне это пишут. Просто довольно сложно не внести мажорную контрибуцию, будучи одним из трех девелоперов в проекте
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Отвечать не буду — пойдем по третьему кругу, и ничего нового не найдем.
В общем, из этой дискуссии мне более понятным стало то состояние дел, о котором я писал , когда говорил об эффективности. Сделаем что-нибудь, а потом будем это улучшать, пока не достигенм приемлемых характерстик...При таком подходе, естественно, ничего иного получиться не может.
Если ситуация с ресурсами остнется прежней — этот подход еще некоторое время будет существовать. Особенно в области т.н. серверного софта, рассчитаннного порой на использование на выделенном сервере, где кроме него ничего и не крутится серьезного... В области же софта для настольных станций это состояние дел и сейчас большие нарекания вызывает, а дальше больше будет. Потому что ясно — рост производительности железа замедлился. А аппетиты расти будут.
Так что это просто болезнь роста. Их уже много всяких было. Минует и эта.
C#.
Вот у меня есть класс (допустим, MyClass), у него внутри есть массив членов другого класса (допустим, MyClassElement) и еще несколько. Все их надо сохранить. И какая разница, будет у меня 2 класса, производные от ISerializable, или будет 2 класса со своими методами Save и Load через BinaryReader/Writer? Даст ли сериализация какие-либо преимущества (сохранение будет производиться только в файл на локальном компе)? Что проще в написании, в отладке?
И где (книги, или инет) можно про сериализацию (в том числе про нововведения в .NET 2.0) почитать на русском? В нашем городе ни одной путёвой книги по C# я не нашел А хочется книжку...
Вот по Visual C++ 6.0 я в свое время брал книгу Дэвида Круглински и кого-то еще (изд-во "Питер"), а по C# 2.0 что-то вроде этого есть?
... << RSDN@Home 1.2.0 alpha rev. 0>>
08.02.06 22:12: Перенесено из '.NET'
Каков глубокий смысл сериализации?
От:
Аноним
Дата:
02.02.06 15:06
Оценка:
Сериализация проще! Для того, чтобы сериализовать, Вам нужно только, чтобы MyClass и MyClassElement имели атрибут Serializable — и все. Если Вы хотите custom сериализацию — Вам надо уже имплементить ISerializable (а надо ли?). Можно конечно и Save и Load через BinaryReader/Writer — но надо ли?
Здравствуйте, MaxxK, Вы писали:
MK>Вот у меня есть класс (допустим, MyClass), у него внутри есть массив членов другого класса (допустим, MyClassElement) и еще несколько. Все их надо сохранить. И какая разница, будет у меня 2 класса, производные от ISerializable, или будет 2 класса со своими методами Save и Load через BinaryReader/Writer? Даст ли сериализация какие-либо преимущества (сохранение будет производиться только в файл на локальном компе)? Что проще в написании, в отладке?
Для сериализации/десериализации нет необходимости реализовывать ISerializable.
Здравствуйте, Oyster, Вы писали: O>Глубокий смысл в том, что для включения сериализации для класса тебе надо написать всего одну строчку кода — указать SerializableAttribute для класса и всё. После этого сериализация/десериализация будет делаться автоматически и тебе не прийдётся для каждого класса писать кастомный код сериализации ручками.
А на размере это сильно сказывается? Где-то ведь нас должны обманывать...
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[2]: Каков глубокий смысл сериализации?
От:
Аноним
Дата:
02.02.06 15:29
Оценка:
Это смотря что эти классы будут содержать и какие у Вас требования к размеру сериализованного файла.
Здравствуйте, MaxxK, Вы писали:
MK>Здравствуйте, Oyster, Вы писали: O>>Глубокий смысл в том, что для включения сериализации для класса тебе надо написать всего одну строчку кода — указать SerializableAttribute для класса и всё. После этого сериализация/десериализация будет делаться автоматически и тебе не прийдётся для каждого класса писать кастомный код сериализации ручками.
MK>А на размере это сильно сказывается? Где-то ведь нас должны обманывать...
Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, MaxxK, Вы писали:
O>Глубокий смысл в том, что для включения сериализации для класса тебе надо написать всего одну строчку кода — указать SerializableAttribute для класса и всё. После этого сериализация/десериализация будет делаться автоматически и тебе не прийдётся для каждого класса писать кастомный код сериализации ручками.
как ни странно это все канает только с открытой датой...
т.е. с данным которые будет и get и set...
но с датой которая только get это почти невозможно, почти потому, что столько ограничений, что проще использовать Write/Read, особенно если говорить о XML. Потому-то что я так и не нашел примера реализации ISerealisable для XML сериализации, если подскажите, буду очень признателен
Здравствуйте, GSL, Вы писали:
GSL>как ни странно это все канает только с открытой датой... GSL>т.е. с данным которые будет и get и set...
GSL>но с датой которая только get это почти невозможно, почти потому, что столько ограничений, что проще использовать Write/Read, особенно если говорить о XML. Потому-то что я так и не нашел примера реализации ISerealisable для XML сериализации, если подскажите, буду очень признателен
Здравствуйте, Пух, Вы писали:
Пух>Здравствуйте, GSL, Вы писали:
GSL>>как ни странно это все канает только с открытой датой... GSL>>т.е. с данным которые будет и get и set...
GSL>>но с датой которая только get это почти невозможно, почти потому, что столько ограничений, что проще использовать Write/Read, особенно если говорить о XML. Потому-то что я так и не нашел примера реализации ISerealisable для XML сериализации, если подскажите, буду очень признателен
Пух>Потому что для кастомной XML-сериализации используют IXmlSerializable. Пух>Пример здесь: http://msdn2.microsoft.com/en-us/library/fhd7bk0a(en-US,VS.80).aspx
Это класическая сериализация, это что бы матом не сказать, заплатка на извествном месте.
Если я желаю что-то руками, то очень хочеться видеть все это в конструкторе, а не в вызове метода после созлания класса.
Но хоть что-то покапаю, если что-то вменяемое получиться расскажу.
И самое главное, теперь придеться ваять 2 метода сериализации один для SOAP и Binary, а другой блин для XML помоему жутко нелогично, если не сказать больше.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Каков глубокий смысл сериализации?
От:
Аноним
Дата:
02.02.06 17:21
Оценка:
Сериализация подойдет для программ типа -HELLO WORLD- а там где есть ресурсоемкие операции сериализация заканчивается
Здравствуйте, xvost, Вы писали:
X>К сожаленгию, у всего есть обратная сторона. X>Аккуратно ручками написанная сериализация через BinaryWriter/BinaryReader примерно в 100 раз быстрее работает чем эта.
Здравствуйте, Nimnul, Вы писали:
N>О да он не просто Serializer а XmlSerializer это говорит о многих преимуществах
Это ты к чему? GSL интересовала именно Xml сериализация в условиях, когда сеттер недоступен.
Здравствуйте, Nimnul, Вы писали:
N>Сериализация подойдет для программ типа -HELLO WORLD- а там где есть ресурсоемкие операции сериализация заканчивается
Похоже, уверждение страдает некоторой расплывчатостью... То есть, если я выполняю в приложении серьезные ресурсоемкие операции, то сериализовать конфиг файл с настройками уже нельзя?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Nimnul, Вы писали:
N>>О да он не просто Serializer а XmlSerializer это говорит о многих преимуществах M>Это ты к чему? GSL интересовала именно Xml сериализация в условиях, когда сеттер недоступен.
На самом деле меня интересовало, как можно средствами .NET сериализовать таблицу настроек, а точнее мне нужно сделать фигову кучу таблиц со всякими забаными струтурами. Эти структуры в 10% случаев таки да настройки, а в 90% просто статические информационные таблицы, например зарегистрированные Whois сервисы, со структурыным и дифференцированным описанием стрктуры доменных имен. ( .com, com.tw, ru, il, co.il ) вообщем много всякой радости. Смысл в том, что эти таблицы readonly, т.е. их либо руками составляют, либо есть сторонняя прога или библиотека, или не важно что, например форма-редактор, но только не пользователь... потому как, не хочеться мне везде копировать структуры или закрывать их вообще от пользователя... но хочеться давать возможность пользователю читать всякие поля, типа описания зоны. Воообщем описание таблиц очень простое, но реализация классов очень сложная. Единсвенный способ который я нашел, это читать промежуточно в простые струтуры. и потос составлять сложные таблицы и классы, вместо того, что бы просто считать сложные в простом и доликвовать нужное после чтения.... но и это по дела, а если что-то изменилось ? опять генерить простые структуры.... вообщем маразм
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Nimnul, Вы писали:
N>>Сериализация подойдет для программ типа -HELLO WORLD- а там где есть ресурсоемкие операции сериализация заканчивается M>Похоже, уверждение страдает некоторой расплывчатостью... То есть, если я выполняю в приложении серьезные ресурсоемкие операции, то сериализовать конфиг файл с настройками уже нельзя?
Можно. Но только "серьезно" и "ресурсоемко"
Опыт — это такая вещь, которая появляется сразу после того, как была нужна...
Re[5]: Каков глубокий смысл сериализации?
От:
Аноним
Дата:
03.02.06 17:22
Оценка:
Merle >>Похоже, уверждение страдает некоторой расплывчатостью... То есть, если я выполняю в приложении серьезные ресурсоемкие операции, то сериализовать конфиг файл с настройками уже нельзя?
Мне бы не составило труда занести настройки в ini файл и работать с ним посредством Systm.IO И вобще зачем ты преувеличиваешь, речь идет о ресурсоемкой задаче а не программе целиком, ведь уже говорили выще что сериализация работает на два порядка медленнее чем System.IO
XmlSerializer задумывался и делался с целью подержки веб-сервисов. Разве не достойная реализация на своем месте?
А то, что кто-то везде пытается её юзать, так это не проблемы авторов.
Здравствуйте, Nimnul, Вы писали:
N>Мне бы не составило труда занести настройки в ini файл и работать с ним посредством Systm.IO
А мне бы составило.. При наличии встроеной сериализации и стандартного XML-я, который по нонешним временам понимает практически любой редактор, пытаться что-то свое изобразить с ini-файлом можно только из любви к искуству.
N>И вобще зачем ты преувеличиваешь, речь идет о ресурсоемкой задаче а не программе целиком, ведь уже говорили выще что сериализация работает на два порядка медленнее чем System.IO
Правильно. Только так же, совершенно верно было замечено, что для 99% задачь скорости штатной сериализации вполне хватает.
Я просто не могу уловить связь между ресурсоемкостью задачи и оправданостью использования штатной сериализации...
Здравствуйте, xvost, Вы писали:
X>К сожаленгию, у всего есть обратная сторона. X>Аккуратно ручками написанная сериализация через BinaryWriter/BinaryReader примерно в 100 раз быстрее работает чем эта.
Binary возможно, а если руками писать/читать XML, то сильно съэкономить не получается.
Здравствуйте, Светлояр, Вы писали:
С>Производительность должна быть везде! А то понапишут одну прогу, вторую третью... по отдельности-то они вроде бы ничего, а вместе — попа!
Здравствуйте, Poluekt, Вы писали:
>> Есть хорошая статья VladD2 на эту тему: Сериализация в .NET. Выпрямляем своими руками P>потому что статья если внимательно присмотреться на самом деле написана о частном случае реализации самодельного сериализатора для датасета.
Кхм... Классно, но причем здесь я?
1. Ссылку на владовскую статью дал не я, как не сложно заметить.
2. Влад сам появляется на форуме и все это высказать можно ему.
3. Вообще-то уже несколько лет на сайте действует механизм привязки обсуждения к статье, то есть, в статье есть ссылка на обсуждение этой статьи в форуме и пройдя по этой ссылке можно написать сообщение, которое будет адресовано непосредственно автору, который, я не сомневаюсь, с удовольствием ответит на все замечания.
P> утверждение что эти фичи не используются в большинстве проектов — детское. проекты которые используют датасеты без этого вопервых врядли можно назвать проектом вовторых таким "проектам" эффективная сериализация не нужна заведомо.
У меня вообще вызывает серьезные сомнения любой проект использующий датасеты, но это уже совсем другой разговор.
P>таким образом эта статья не имеет никакого практического смысла.
Почему? Для кого-то вполне имеет.
P>любой наверное догадается что если передача данных по сети съедает непомерное количество полосы то надо что то делать. например передать только те данные которые нужны а излишки опустить. если бюджет позволяет это переписывать самому.
Зачем самому, если я правильно помню, то у датасета есть стандартный способ отослать только изменения.
P>автор приходит к выводу что датасет — большой и сложный объект физически. передача большого объкта по сети не должна занимать много места. предложенная альтернатива — передача объекта имеющего отдаленное сходство с датасетом.
Ну, все логично, а что не так? В любом случае надо чем-то жертвовать, предложен один из вариантов жертвы, в чем проблема? Жертва не устраивает?
P>поэтому фраза "Есть хорошая статья" и так же название "Выпрямляем своими руками" НЕКОРРЕКТНЫ.
Это не ко мне. Я её даже не читал толком, поэтому не могу ничего сказать по поводу ее хорошести или плохости..
P> У неосведомленных читателей складывается устойчивое впечатление что P>1. статью надо использовать как библию
Хм.. "Хорошая" == "использовать как библию"? Надо будет попробовать, но вообще это довольно вольная интерпретация.
P>2. на практике средний программист может написать реализацию сериализатора лучше чем МС.
Ну, если пробовать не будет, то точно не напишет. Хотя по моему мнению собственноручная сериализация довольно редкий зверек и как правило нафиг не надо ее писать.
P>оба положения неверны.
Естественно. Забавно другое, как много можно сделать выводов из фразы "хорошая статья"
P>я привел ссылку которая объясняет как передать датасет более эффективным способом если кому нужно.
Ну это к Владу.
P>я с удовольствием почитаю любую статью которая дает — либо интересный _практический_ результат при _адекватных_ затратах либо описывает _интересную_ подход/технику в производстве качественных продуктов.
Я тоже. Я такую даже с удовольствием напишу...
P>у меня нет никаких сомнений в умственном развитии автора. просто эта статья содержит минимум полезной информации и с учетом напыщенности названия и с учетом что ее теперь распространяют как "хорошая" я позволил себе этот пост, т.к. она искажает действительность без особой нужды.
Вот в таких случаях надо IMHO добавлять, впрочем это пусть Влад бодается...
P>я не рад только тому что он тратит время на пустое. и не рад тому что глупые статьи будут висеть в инете годами. надо быть более отвественным к тому что публикуешь. надо немного самокритики добавить. как известно что написано на клавиатуре то не вырубишь молотком.
Отлично. Вот теперь все это Владу, в комментарии к его статье.
P. S.
Прочитать ее теперь что ли?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Мы уже победили, просто это еще не так заметно...
Re[10]: Каков глубокий смысл сериализации?
От:
Аноним
Дата:
08.02.06 14:27
Оценка:
почитай.
я помню что это Ойстер был. однако ты сам вызвался позвать В2
писать реплики на статью нет смысла. на самом деле должен быть "редактор" который бы фильтровал базар. но я в рсдн никого не знаю.
Здравствуйте, xvost, Вы писали:
X>Аккуратно ручками написанная сериализация через BinaryWriter/BinaryReader примерно в 100 раз быстрее работает чем эта.
Дык, окуратно написанная автоматическая бинарная сериализация будет работать приблизительно так же быстро как и написанная ручками. Так что это вопрос конкретной сериализации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Poluekt, Вы писали:
P>потому что статья если внимательно присмотреться на самом деле написана о частном случае реализации самодельного сериализатора для датасета.
Вообще-то статья о скорости сериализации. Но видимо ты это не заметил.
P> причем реализация практически ничего не поддерживает (ни констрайны ни индексы ни релейшны).
Реализация поддерживает сериализацию данных. А именно их обычно и требуется передавать по сети. Не так ли?
P> утверждение что эти фичи не используются в большинстве проектов — детское.
При сериализации учитываются ячейки, содержащие DbNull и версии строк, но не поддерживается сериализация ограничений (constrains), связей между таблицами (relations) и некоторых других аспектов. Этот сериализатор можно с успехом применить во многих приложениях, так как неподдерживаемые возможности используются на практике не так часто. К тому же несложно доделать сериализацию необходимых возможностей DataSet-а самостоятельно. Размер сериализованных данных при этом не должен серьезно увеличиться, так как все возможности, для которых я не реализовал сериализацию, являются чисто декларативными.
Связи и ограничения, если они очень нужны можно просто влючить вручную после загрузки информации. Это не проблема. К тому же я упомянул, что если кому-то это нужно, он может дописать отсуствующую функциональность сам. В конце концов я это не коммерческий код, а всего лишь пример. Да и я не подрежался работать за кого-то.
P> проекты которые используют датасеты без этого вопервых врядли можно назвать проектом вовторых таким "проектам" эффективная сериализация не нужна заведомо.
Нда, катигоричность недостойная даже чтобы с ней спорить.
P>таким образом эта статья не имеет никакого практического смысла.
Хм. Слава богу об этом не тебе судить. Как видишь, многим эта статья понравилась, и думаю, что кому-нибудь она принесла пользу.
Более того, в свое время я гворил с одним, довольно известным около-Майкросовстовским товарищем и он очень удивился услышав от меня о низкой эффективности сериализации датасотов. Он обещал передать эту информацию куда следует. Уж не знаю сделал он это или нет. Одно точно извесно, что проблема была в МС признана и во втором фрэймворке исправлена: http://msdn2.microsoft.com/ex6y04yf.aspx
Binary Serialization for the DataSet
This new option enables a DataSet and a DataTable to be serialized in binary format when using binary transports over remoting. In most cases this will result great performance improvements and a noticeable reduction in both memory and CPU usage when using DataSet/DataTable objects in applications that use remoting to connect to different tiers.
В общем, чем критиковать других за то, что они что-то сделали, лучше сделай сам хоть что-то полезное сам.
Отвечать на все дальнейшее напышенное хамство и неуважение у меня желания нет. Ты привел ссылку которая появилсь 04.08.2004, а статья о которой ты тут изволишь разглогольствовать появилась 02.09.2003, то есть где-то на год раньше. Причем не факт появилась би эта вторая статья не будь первой.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, MaxxK, Вы писали:
PD>У меня есть страшное подозрение, почему Микрософт так любит сериализацию.
А причем тут вообще MS?
Персистентность важна и нужна независимо от MS.
Здравствуйте, bkat, Вы писали:
B>А причем тут вообще MS? B>Персистентность важна и нужна независимо от MS.
Боюсь, флейм сейчас начнется. Ну да ладно
В конечном счете речь идет о сохранении чего-то в файле (я не забыл про всякие memory stream, но опустим их пока что). А файл (не file Виртовского паскаля, а натуральный файл) есть структура прямого доступа вообще-то. К персистентности у меня никаких возражений нет, но почему эту персистентность надо делать, записывая данные именно последовательно — это я в общем случае не понимаю (в частных случаях вполне могу быть согласен).
Сохранять данные последовательно во многих случаях вполне разумно. В других — ИМХО совершенно неразумно, так как их сохранение по природе своей не есть выкладывание в линию. Иногда лучше сначала зарезервировать в файле некоторое место, просто не записать туда ничего, выложить в файл все остальное, потом вернуться туда и записать пропущенное. К примеру, разреженную матрицу ИМХО именно так и следует записывать — оставить место для количества ненулевых элементов (4 байта), выложить все тройки (row,col,value), по ходу действия подсчитав их количество, потом спозиционироваться на место для этих 4 байтов и записать это количество. Можно, конечно, в 2 прохода сделать, тогда будет именно сериализация, но, простите, зачем ? Во имя принципов ?
Лично мне в моей работе пришлось однажды заняться тем, что можно назвать "выкладывание в файл". Но вот сериализацией назвать это язык не поворачивается. Потому что там создавались довольно сложные структуры, частями записывались в файл (хранить в ОП не мог — там десятки и сотни Мб), потом в файле я возвращался назад, заполнял их блоки управления, потом опять назад, заполнял блоки управления более высокого уровня и т.д.
А вообще должен сказать, что никогда никаких проблем с записью в файл у меня не было. Еще в DOS времена как освоил fopen-fwrite-fread-fseek-fclose, так до сих пор и пользуюсь. Ну разве что иногда перехожу на CreateFile etc. И, конечно, файл-мэппинги. Как, кстати, насчет их ? Там ведь, по большому счету, то же выкладывание в файл идет (если надо файл сохранить, конечно), только вот кому захочется при работе файл-мэппингом запретить себе свободно перемещать указатель — я посмотреть бы хотел.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>В конечном счете речь идет о сохранении чего-то в файле (я не забыл про всякие memory stream, но опустим их пока что). А файл (не file Виртовского паскаля, а натуральный файл) есть структура прямого доступа вообще-то. К персистентности у меня никаких возражений нет, но почему эту персистентность надо делать, записывая данные именно последовательно — это я в общем случае не понимаю (в частных случаях вполне могу быть согласен).
VD>Это элементарно Ватсон!
VD>1. Файл есть еденица хранения данных. Когда речь идет о записи в файл, то речь идет о интфейсе файловой системы. VD>2. Сериализация нужна не для записи в файл, а для представления состояний объекта или графа объектов в виде пригодном для хранения и передачи. VD>3. Есть много случаев когда данные удобно передавать/хранить в последовательной форме. Например, при передаче их по сети.
VD>Отсюда люди ввели абстракцию потоков (streams) и их классификацию от самых приметивных последовательных, до специализированных поддерживющих перемещение по содержимому.
Не надо путать два понятия
1. Выкладывание объекта в линию.
2. Последовательный механизм реализации выкладывания объекта в линию.
Первое — абсолютно законно и может требоваться в самых разных случаях.
Второе — обязательно только для выкладывания в текстовый файл или поток, который физически не допускает перемещения в нем.
Если поток допускает перемещение в нем (любой файл на диске), он ИМХО должен поддерживать механизм перемещения. А если он поддерживает — то и вопроса нет. То, о чем я писал, говоря о своей задаче — и есть выкладывание в линию (в файл), но механизм этого выкладывания отнюдь не последовательный. И FILE* в этом смысле — тоже поток, хотя его так и не называют.
И второе. Нет причин, по которым механизм сериализации должен использоваться для каких бы то ни было действий в оперативной памяти, (если не предполагается в дальнейшем передавать сериализованные данные на последовательное устройство). Оперативная память есть RAM (Random access memory) и превращение ее в Sequential access memory (или address space, не важно) ничем не обосновано.
Здравствуйте, bkat, Вы писали:
B>Проблема видимо только в первом элементе "число ненулевых элементов" B>Его можно писать в конце.
Нет, не пойдет. Если ты его запишешь в конец, как ты отличишь его от очередной тройки ? Файл-то в действительности будет двоичный, это я просто в текстовом виде привел для наглядности. И я вовсе не обещаю, что после этой матрицы там не будет других данных.
Можно, конечно, после матрицы всех троек -1 записать как признак конца. Но и это некорректно — а если нумерация строк матрицы не с нуля, а произвольная ?
А если я структуру вывода усложню ? Она. кстати, там совсем неэффективная, я только для примера привел ее. Лучше хранить не тройки, а
число ненулевых строк
для каждой ненулевой строки (т.е имеющей хоть один ненулевой элемент)
ее номер
число ненулевых элементов
col, value для каждого элемента
У меня в коде мало что изменится. А ты что придумаешь ?
Но главное не в этом. Придумать во многих случаях можно однопроходной алгоритм. Вопрос серьезнее — зачем придумывать странные структуры данных, когда есть простое и элегантное решение, и единственно, что оно требует — fseek ?
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Ну, извини. Что вижу, то и говрю. Обижать тебя ни малейшего желания не было.
PD>Ok. Но если это повторится — вынужден буду прекратить дискуссию.
Еще раз извиняюсь, если задел. Постораюсь это не делать. Но и ты не принимай указание на твои ошибки за оскорбление.
PD>Если ключевое слово — сохранение состояния, а не в последовательную форму, то я готов немедленно согласиться и закончить дискуссию. Если сериализация есть сохранение состояния (в последовательную, индексно-последовательную, бинарное дерево, БД, zip-архив и т.д. и т.п) — я согласен и готов не спорить о терминах. Только вот по крайней мере MFC сериализация требует именно PD>в последовательную форму. Насчет .Net — не берусь судить, не настолько хорошо знаю.
Последователная форма в данном случае означает "форма с которой легко манипулировать". Если говорить не псевдонаучным языком, а по простому. Сериализация — это превращение состояния графа объектов в некую простую структуру данных. Онятно, что некое бинарное дерево вряд ил можно назвать простой структурой. По этому в МФЦ или других фрэймворках под простой структурой понимают или массив байтов или поток. Делается это исключительно по той причине, что это самые примитивные абстракции в следствии чего с ними можно манипулировать наиболее абстрано. Их можно передавать по сети, записывать в файлы, шифровать, пихать в БД...
Что косается сохранения в БД, то тут могут быть разночтения. В БД можно сохранить состояние в виде BLOB-а, а можно в виде записей БД где поля объектов отражаются на колонки таблиц БД. Второе обычно называют persistens хотя иногда и сериализацией. Второе не очень верно, так как все же состояние хотя и сохраняется, но не в простой форме. В общем, то вотрой способ более гибок, но более расточителен.
Но еще раз замечу, что сериализация не подразумевает того, что она должна делать последовательно. Важно, что в итоге ты получашь поток или массив. Формировать же его можно по разному. И это уже вопрос реализации и эффектиности. Причем не нужно смешивать вопрос обстракции (поток/массив) с вопросами эффективности (того как пихать данные в эти самые массивы/потоки).
PD>Да бога ради, я на 100% согласен. В конце концов я ведь тоже в файл выкладывал, а он после закрытия уж на 100% последовательность байт, с этим не поспоришь.
Именно. Но еще раз. Не надо применять термин "выкладывал". Записывал будет понятнее и непротиворичивее.
PD> Я же совсем не об этом говорю, а о том, что сериализация, как она реализована (в MFC) требует, чтобы механизм (алгоритм) был последовательного выкладывания. Вот эта идея мне в общем случае не кажется верной.
В MFC сделано решение позволяющее уростить сериализацию. И ты волен его не использовать. MFC просто пытается облегчить тебе жизнь. Я откроевнно говоря уже не помню всех тонкостей, но если не ошибаюсь ты можешь перехватить процесс сериализации и сделать его вручную.
Опять же то, что MFC требует чтобы в конце процесса получилась та самая последовательная форма не подразумевает что обязательно нужно последовательно формировать эти данные. Ты можешь сформировать их в буфере и отдать уже результат.
Так что опять констатируем, что MFC предлагает интерфейс (абстракцию) и одну из форм реализации, а ты обижашся на MFC говоря, что интерфейс тебе не нравится, так как он не позволяет пременять алгоритм который тебе нравится. В этом и заключается ошибка, на мой взгляд. MFC не подразумевает того, что запись этого самого состояния нужно делать именно через него. Более того, создатели MFC скоре всего и рассчитывали на то, что если кому-то потребуется более сложный механизм, то он просто сформирует данные в отдельном буфере и уже из него отдаст MFC данные через предопределенный ею интерфейс.
VD>>Естественно! Вообще многое не обязательно. Например, не обязательно выходить на улицу в одежде или при размышлениях пользоваться логикой.
PD>Глупо. Аргументы подобного уровня заставляют только сомневаться в правоте аргументирующего.
Это называется сарказм. Ты сомневашся в совершенно очевидных, на мой взгляд, вещах. Я не говорю тебе об этом открыто, а даю понять это приведением абсурдных аналогий. Так что могу посоветовать только по чаще включать юмор и улыбаться.
PD>Ох, надоело мне это упоминание больших проектов. Откуда тебе знать, в каких проектах я участвовал, что ты все время пытаешься мне это тыкать ? Проекта с суммарным размером исходников в 10 Мб хватит?
Я сужу по высказваниям. И, кстати, если ты заметил не говори тебе, что ты не участвовал в больших проектах. Просто твое не верное, на мой взгляд, отношение к абстракциям явно не способствует при работе над большими проектами.
PD>Ну спасибо, просветил. Без тебя я про структурное программирование и ООП так и не узнал бы .
Про ООП узнать мало. Еще нужно вжиться в него. Не прийми следующие слова за оскобление, но я четко вижу, что ты плохо вжился в ООП. Твое отношение к абстракциям крайне не верное. Ты смотришь на них сквозь призму реализации, а это не верно!
PD>А я и не создавал. Код, который я писал, вполне успешно работает на сотнях компьютеров, и до сих пор никто не жаловался.
Если ты вместо того, чтобы пользоваться готовыми абстракциями будешь создавать собственные аргументируя это тем, что "так быстрее", то точно создашь проблемы себе и окружающим. Что же до работы на сотнях компьюетров, то мои ранние программы работали на тысячах компьютеров, но я сказал бы, что написаны они били припохабно. Так что тут зависимости нет. Работать можно заставить даже самый бездарный код. Был бы напор и желением. А вот создать код который не только что-то делает, но и легко модифицируется и заменяется на другой елси это потребуется — это куда более сожная задача. И в больших проектах она востребована как никогда. От того я и упоминаю бльшие проекты.
PD>Да уж, действительно мелочи. будет ли в результате файл размером в 10 Кб или 10 Мб, будет ли это работать быстро или медленно — это все мелочи. Зато принципы будут соблюдены.
Раскажи мне, плиз, как связаны размеры файлов и скорость работы кода с тем, что интерфейс сериализации требует последовательной записи?
VD>>Сериализация вообще не является последовательным выкладыванием полей в поток (в прочем как и объетов). Сериализация — это преобразование состояния объекта в последовательную форму. То как это делается уже вторично. Ты можещь использовать разнообразные промежуточные структуры, сохранять только часть полей или даже некоторую функцию от состояния объекта по которой потом можно будет востановить это состояние. Это уже все детали. Главное, что в итоге ты должен получить массив байтов/поток в ктором находится состояние графа объектов.
PD>В письме к Sinclair я сформулировал конкретно задачу (с матрицей). Напиши свое решение, обсудим. Хватит обо общих принциах говорить, код в студию.
Я не буду писать тебе кокретных решений. Я тебе просто попробую написать очень простой код и донести его смысл. Сериализацию можно представить как функцию:
Stream Serialize(SomeType roor)
{
...
}
Ты волен реализовать эту функцию как угодно. Единственное что ты не должен менять — это сигнатуру этой функции, так как — это интерфейс между тобой и остальным миром.
Все твои рассуждения связанные со скоростью и компактностью — это рассуждения о тех трех точках. Ты же пыташся начать рассуждать о сигнатуре функции. Вот в этом и заключается ошибка.
Пойми, что твоя функция универсальна пока она соблюдает этот интерфейс. И это очень важно!
VD>>>>Вообще данный вопрс показывает то что большинство твоих проблем происходят из-за того, что ты не умешь мыслить абстракциями.
PD>Меня, честно говоря, сильно удивляет то, что ты, вроде бы неглупый человек, столь несерьезно относишься к своим заявлениям. Неужели трудно понять из моих выступлений, что мыслить твоими любимыми абстракциями я умею, но для меня это лишь половина задачи. Наверное. что такое поток, я понимаю, но бездумно использовать эту концепцию, не разобравшись в том, как она может быть в данной ситуации реализована, я не буду.
И все же ты обежашся на правду. Не, конечно может быть я ошибаюсь, но то что я говорю — это то что я вижу. Пойми другие просто пройдут мимо, возможно зларадно хихикнув. Я тебе сказал, то что думаю, и ты обидился на этом. Ну, могу конечно тоже промолчать. Лучше тебе от этого вряд ли станет. Но за-то не обно.
Если абстрогироваться от обит и поптыаться проанилизировать сви ошибки, то ты увидишь, что умение мыслить абстракциями как раз и подразумевает при размышлениях возможность отрешитья от эффективности реализации. Тебе достаточно общей характеристики для твоих размышлений. Следующим шагом будет умение выбрать компромис между универсальностью и эффективностью. Ты явно (опять же на мой взгляд) слишком сильно зациклен на эффективности от того злишся на абстракции. А это не верно! Ну, не виноваты абстракции ни в чем.
PD>Для тебя — есть объект, надо сохранить, выведем поток. Все ясно. PD>Для меня — есть объект, надо сохранить. Можно выести в поток, а это хорошо будет ? Размер файла ? Скорость ? Хорошо ? Тогда ладно. Нет ? А что другое можно предложить ? И т.д.
Во-вот. Для меня есть здача. Далее я пытаюсь выбрать паттерны для ее решения и абстракции для представления сущьностей учавствующих в этом решении. Если задача сохранить состояние объекта в файл и загрузить его в последствии, и при этом нет нужны в анализе этого состояния, то я выберу паттерн "Сериализация". Если я выбрал это паттерн, то совершенно логично, что абстракция "Состояние" подразумеваемая этим паттерном будет поток или массив байтов. Так же совершенно логично, что сам процесс сериализации будет представлен функцией параметром которой является сериализуемый объект, а возвращаемым значением этотм самый потк (короче как в примере выше). Выбор потока обуславливается тем, что это самая универсальная абстракция из пригодных для представления состояния.
Далее я задумаюсь над реализацией той самой функции. Вот тут я как и ты задумаюсь над тем как более эффективно сериализовать состояние графа объектов. И о том, что мне важнее универсальность, скорость, размер сериализованного представления или какое-то сочетание этих аспектов. Например, если размер и скорость мне не очень важны, то я могу воспользоваться не очень эффективным встроенным механизмом сериализации в дотнете. Если мне важен размер, то я могу реализовать автоматическую сериализацния на без рефлексии. А если мне нужна и скорость, и компактность результата, то скорее всего я создам метапрограмму генерирующую код для некоторого списка классов.
Если задуматься над тем что за структуры данных я буду использовать при реализации механизма сериализации, то тоже нужно проанализировать кучу входных посылок. Например, скольк большой размер будет иметь сериализованное состояние. Если это гигабайты, то я скорее всего задумаюсь над тем целисообразно ли применять сериализацию в данном случае. И если все же решу, что целисообразно, то задумаюсь над использованием эффективных промежуточных структур и над алгоритмами. В общем, этих "если" бесконечное множество. Так что обсужадать их в общем бессмысленно.
Важно другое. У нас в корне отличается стадия анализа. Ты уже на самых ранних стадиях размышлений сваливашся на обсуждение деталией, то есть на очень низкий уровень абстракции. Я же пытаюсь этго не допустить. Только и всего.
PD>А если ее нельзя реализовать в данной ситуации эффективно ? Нельзя, и все. А неэффективно — не принимается. Ваше решение ?
Значит имеет место один из двух фактов:
1. Ты недостаточно подготовлен для грамотного решения задачи.
2. Эта абстракция неподходит и надо искать другую.
Но не в коем случае не нужно "подстругивать" абстракцию.
PD>У меня их тоже нет.
Вижу.
PD>Вообще забавно смотреть на твой менторский тон. "Возможно, ты не знаешь..." и дальше популярное объяснение. Знаю, не волнуйся.
Тем страннее.
PD> И не изучаю, а закончил небольшой проект на нем. Увы, заказчик потребовал использовать NHibernate. Клиент всегда прав, как известно. Ну что же, по крайней мере я постарался сделать так, чтобы запросы к БД были не менее эффективными, чем на чистом SQL.
Забавные клиенты пошби. Так глядишь и через некоторое время клинеты начнут заставлять соблюдать чистоту абстракций и грамотность форматирования кода.
PD>Кстати, разъясни фразу "приблизительно в 10 раз менее эффективны, чем аналогичные исползующие прямую работу с БД". Ты утверждаешь, что у меня в 10 раз больше данных выбирается, или в 10 раз больше модификаций делается, или что ? Если это — можешь быть уверен, что это далеко не так, ничего лишнего там выбираться не будет.
Под эффективностью тут имеется в виду скорость работы. O/RMapper-ы в принципе не эффективны. Пока что никому не удалось создать реализацию O/R Mapping-а которая была бы соизмерима со скоростью добротно написанного приложения работающего с БД по сдерствам запросов.
VD>>Небывает уровеня реализации. Быают разные реализации абстракций и (иногда) алгоритмические ограничения абстракций. Например, связанный список накладывает принципиальные ограничения на скорость последовательного доступа. Вот только сериализация то тут причем?
PD>Не знаю. Я могу еще заявить, что скорость ввода символов с клавиатуры человеком накладывает принципиальные ограничения на возможность вручную ввести "Войну и Мир" за одни час, и спросить — а при чем здесь сериализация? Ты задал этот вопрос, ты и отвечай. Я про связанные списки вообще ничего не говорил.
Я это сказал к тому, что требование вовращать данные в сериализованной форме не накладывает никаких ограничений, в отличии от выбора абстракции списка.
PD>Да давно я во всем этом разобрался. Твоя ошибка в том. что ты почему-то решил, что мне неизвестны элементарные истины, и пытаешься меня им научить, А для меня эти истины — просто нечто рабочее, о чем я и думаю-то мимоходом.
Незаметно, что-то.
PD> Стек так стек, поток так поток, дерево так дерево. Все замечательно. А теперь давайте думать — а как это сюда уляжется. С этим потоком мне уютно будет ? Нет ? А куда выводить надо, только в файл ? Да, А тогда долой отсюда этот поток. В файл я и по-другому записать могу. Вот и все.
Вот-вот. Это не умение. Это черт знает что. "А куда выводить?... Долой потк..." Это и есть неумение пользоваться абстракциями. То есть ты конечно представляешь, что такое пото и файл, но зачем нужен этот самый поток ты не то чтобы не знашь, а это просто не ложится в твое мировозрение. Ты приципиально не мыслишь о программе, как о наборе слабосвязанных модулей соедененных интерфейсами. Ты смотришь на интерфейсы как не нечто требуемое алгоритму.
Вот это и есть неумение использовать абстрации.
PD>Вот тебе абстракция — линейный список с возможностью доступа по индексу к имеющимся элементам? Годится абстракция?
Годится.
PD>А теперь ответь — можно ли использовать эту абстракцию для хранения данных, если
PD>a)
PD>1) количество элементов очень велико
Не влияет на выбор абстракции. PD>2) операции вставки/удаления в начало производятся очень часто
Не влияет на выбор абстракции. PD>3) операции доступа по индексу производятся очень редко
Единственный важный факт из перечисленных. PD>4) скорость работы критична
Не влияет на выбор абстракции.
Ответ будет один — да, можно.
PD>б)
PD>1) количество элементов очень велико
Единственный важный факт из перечисленных. PD>2) операции вставки/удаления в начало производятся очень редко
Единственный важный факт из перечисленных. PD>3) операции доступа по индексу производятся очень часто
Единственный важный факт из перечисленных. PD>4) скорость работы критична
Единственный важный факт из перечисленных.
Тоже можно.
PD>Непременное условие — о реализации ты ничего не знаешь, как ты и хотел. Иными словами, после того, как ты ответишь на оба вопроса, я тебе сообщу, какая именно реализация используется в библиотеке, которую ты должен использовать.
А мне не нужно сообщать. Я выбрал абстракцию. Твои условия ей не противоречат. А вот реализацию абстракции я выбиру сам исходя из тех самых критериев которые ты перечислил. Причем критерии вроде "количество элементов очень велико" для меня явлюятся пустым звуком. "Очень велико" может означать разные вещи для разных людей или разных уловий.
PD>И просьба не отвечать — дескать, если меня не устроит эта реализация, я другую сделаю. Нет у тебя такого права.
А это условие чтобы прикольнее было?
PD>Ты сам от него отказался.
Когда это? Я всего лишь отделил выбор абстракции, от выбора ее реализации. Я определился с тем, что для меня приемлема конкретная абстракция (список с произвольным доступом), и теперь могу определиться с конретной реализацей. Причем реализацию я могу и заменить в последствии. А вот абстракция уже более стабильная сущность.
PD>Только просьба — ответь прямо — да или нет ? Ты же говоришь — оценить пригодность абстракции можно ничего не зная о ее конкретной реализации, так ? Ну вот и оцени — пригодно или нет.
Хм. А как же можно не говорить да, или нет?
VD>>Ну, нет никаких проблем для того, чтобы эффективно сериализовать все что угодно в поток байтов. Ну, нет! Ты можешь банально сделать это в помяти и вернуть требуемый интерфейс воспользовавшись каким-нибудь MemoryStream.
PD>Памяти нет
Куда она делась? Или это такая Матрица? "Ложки нет..."
>>Так зачем же жертвовать абстракцией и писать какие-то частные клагоритмы которые можно использовать только в отдельных случаях?
PD>Для того, чтобы самолет летал быстрее, чем паровоз ездит
Полетят у тебя они оба в одном направлении с такими подходами... под откос.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и не надо. Вполне согласен. А вот надо ли при записи в файл использовать сериализацию ?
Хороший вопрос. Может его нужно было решать до того как ты начал использовать сериализацию?
А то если ты выбрал сериализацию для записи данных которые потом прийдется анализировать или читать по отдельности, то ты явно ошибся с выбором абстракции. Ну, глупо представлять файл БД, например, как некий BLOB.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не пойдет. Если ты его запишешь в конец, как ты отличишь его от очередной тройки ? Файл-то в действительности будет двоичный, это я просто в текстовом виде привел для наглядности. И я вовсе не обещаю, что после этой матрицы там не будет других данных.
PD>Можно, конечно, после матрицы всех троек -1 записать как признак конца. Но и это некорректно —
А что же тут не корректного то?
PD>а если нумерация строк матрицы не с нуля, а произвольная ?
1. Это уже выдумывание нереальных условий в целях доказательства ради доказательства.
2. Какая разница, что использовать в качестве условия остановки -1 или int.MinValue? Используй его или нижнюю границу минус еденицу.
В общем, это разговор не очем. Для конкретного случая, конкретная реализация. А в общем, случае единственное разумное решение — это кэшировние результата. Нефига экономить на спичках.
Пойми, что большинство людей с тобой общащихся вообще не станут писать сериализацию вручную если на то нет очень весомых оснований. И оптимизировать формат тоже не станут. Ну, и что если у меня файл будет не 100 байт, а килобаймт? Современной системе это до лампочки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Если нумерация строк произвольная (что имеет весьма слабый смысл), то достаточно в заголовке записать эти данные вместе с размерностью матрицы. Если смещения заранее известны, то даже этого не требуется. Я тебе заранее могу сказать, что вариант с маркером конца матрицы будет работать как минимум не хуже варианта с префиксом длины, что бы ты ни придумал. Потому, что математика так устроена.
Кстати, вариант с длинной плох еще тем, что в случае повреждения данных вместо распознования ошибки формата можно легко получить исключение выхода за пределы массива и т.п.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kan_izh, Вы писали:
_>Serialization от слова "serial" — "последовательный". Сериализовать можно не с целью сохранения состояния, а, например, для передачи по сети.
При передаче по сети, тоже передается состояние.
_>Если же сохранение состояния, то persistence. _>В поток сериализуют, а в БД персистят.
Бывает по рзному. Бывает, что и БД сериализуют. Но в общем верно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, bkat, Вы писали:
B>Потом ты ехидно заявил, что BG недоучка, не знает о прямом доступе B>и потому везде пихает сериализацию.
М-да... Я и не думал, что мою шутку кто-то так понять ухитрится. Или ты впрямь решил, что я считаю, будто вся MS не умеет работать с файлами прямого доступа ?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
VD>Пойми, что большинство людей с тобой общащихся вообще не станут писать сериализацию вручную если на то нет очень весомых оснований. И оптимизировать формат тоже не станут.
Т.е будут хранить матрицу целиком ?
Ну, и что если у меня файл будет не 100 байт, а килобаймт? Современной системе это до лампочки.
Маленькая поправка.
Исходная матрица 1000*1000. Размер 4 Мб.
Ненулевых элементов 5%. Их объем при хранении 1000*1000*0.05 * 3 * 4 = 600 Кб. Можно и меньше, если более оптимальным способом хранить
Как говорят в Одессе, две большие разницы. 4 Мб и 600 Кб. Если тебе это до лампочки — на здоровье.
И зачем это люди архиваторы используют ? Хранили бы файлы как есть. Современной системе это до лампочки!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>я точно так же стану использовать -1 в качестве маркера конца списка ячеек/строк. И размер данных будет таким же, как у тебя. Только fseek не будет нужен.
Хорошо, на тебе еще один пример. Для каждой строки должна храниться некая ее характеристика (ну, к примеру, среднее всех элементов). При вводе строки, для которых эта характеристика не соответствует некоему критерию, должны пропускаться. Характеристика вычисляется по каждой строке и заранее не известна.
А впрочем, зачем я все это доказываю? Ты же достаточно грамотный программист и не можешь не понимать, что во многих случаях нельзя сделать однопроходной алгоритм выкладывания без возвратов в файле. Ну не можешь ты это не понимать. иногда можно обойтись без этого, чаще — нельзя. Так зачем же доказывать недоказуемое ? Только для того, чтобы оправдать свою изначальную позицию ?
S>Вот давай теперь я тебе задам задачку: та же матрица, вот только нужно компрессировать ее данные при помощи Gzip. Требования те же: никакой дополнительной памяти, писать все в один проход. Мой код не изменится вообще — я просто отдам сериализатору в качестве таргета GzipStream.
Как красиво! А этот самый GZipStream внутри себя так-таки и не использует позиционирование в ? И не использукт дополнительной памяти ? И точно однопроходной ? Код его можно посмотреть ?
PD>>Ну и не надо. Вполне согласен. А вот надо ли при записи в файл использовать сериализацию ?
VD>Хороший вопрос. Может его нужно было решать до того как ты начал использовать сериализацию?
Уф, наконец-то первое здравое размышление в этой дискуссии. Я же именно об этом и говорю. Я разве против сериализации, когда она оправдана алгоритмом ? Ни в коем случае, я целиком за!!! Я против того, что сериализация бездумно используется там, где алгоритм ее вовсе не предполагает. Например, для копирования объекта в памяти. Например, для вывода объекта на диск при том, что этот вывод достаточно сложен и не укладывается в один линейный проход. И т.д.
Меня не сериализация беспокоит. Сама по себе она вполне законный метод, безусловно имеющий право на существование. Мне не нравится, когда ее применяют там, где совсем не надо. А тем более пытаются доказать, что применять ее все же стоит даже в тех случаях, когда она явно противоречит алгоритму (последнее утверждение есть непосредственно камешек в твой и Sinclair огороды)
В общем, не сотвори себе кумира из сериализации. Да и из всего другого тоже.
Здравствуйте, VladD2, Вы писали:
PD>>2. Двухпроходной алгоритм не рассматривается.
VD>А почему собственно?
А потому, что на него нужно лишнее время.
VD>Хотя это конечно частный случай. Одако не вижу проблем в том, чтобы сформировать нужный список в памяти,
Т.е использовать дополнительную память.
VD>И не надо рассказывать про скорость и лишнюю память. Память ты занимашь на наносекунды. Объем ее незначителен.
А откуда ты знаешь, что незначителен ? В моей программе (там, правда, не разреженная тарица была, а нечто более сложное) суммарный размер выходных данных примерно 100 Мб. И хранить промежуточные данные мне негде.
VD>ЗЫ
VD>И, кстати, натянутость самой ситуации снова настораживает. Значит при хранинии данных в памяти (которая как извесно примерно на 3 порядка дароже) ты выбирашь плоские массивы, а при хранении на диске вдрг слезно озаботился компактностью. Странно это.
Нет, не странно. Дело в том. что, к примеру, выполнять операции матричной алгебры на компактированных матрицах как бы это выразиться ... не очень удобно . Перемножение еще туда-сюда, а вот нахождение, скажем, собственных значений и векторов (диагонализация) — лично я таких алгоритмов не знаю. Там и без того N^3 по методу Якоби, а если еще в сжатом виде хранить — ждать будем до второго пришествия. А матрица именно разреженная, и очень сильно (говорю о задачах, которые решал во времена своих химических дел — расчет ИК-спектров, квантовая химия)
VD>Скорее всего матрица просто не самое эффективное представление данных.
Или нужно использовать хэш-таблицу, или еще что-то. А при этом и слгоритмы сериализации опменяются.
Предложи для начала алгоритм диагонализации матрицы, представленных в виде хеш-таблицы
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хорошо, на тебе еще один пример. Для каждой строки должна храниться некая ее характеристика (ну, к примеру, среднее всех элементов). При вводе строки, для которых эта характеристика не соответствует некоему критерию, должны пропускаться. Характеристика вычисляется по каждой строке и заранее не известна.
Павел, ты начинаешь страдать нездоровой фигней. Я тебе уже показал, что любая мало-мальски реалистичная задача решается без завышения требований к окружению.
PD>А впрочем, зачем я все это доказываю? Ты же достаточно грамотный программист и не можешь не понимать, что во многих случаях нельзя сделать однопроходной алгоритм выкладывания без возвратов в файле. Ну не можешь ты это не понимать. иногда можно обойтись без этого, чаще — нельзя.
Ну с чего это "чаще-нельзя"??? Павел, ты опасно заблуждаешься. Все как раз наоборот. Я вот в жизни не встречал еще необходимости делать fseek при сохранении. Обрати внимание, что когда ты пытаешься приводить свои реальные примеры, оказывается, что fseek был нафиг не нужен. Странно, правда? Поэтому твое впечатление о том, что чаще — нельзя, напрямую связано с тем, что ты просто пихал fseek где надо и где не надо.
S>>Вот давай теперь я тебе задам задачку: та же матрица, вот только нужно компрессировать ее данные при помощи Gzip. Требования те же: никакой дополнительной памяти, писать все в один проход. Мой код не изменится вообще — я просто отдам сериализатору в качестве таргета GzipStream. PD>Как красиво! А этот самый GZipStream внутри себя так-таки и не использует позиционирование в ?
Нет, не использует. Он был специально заточен под работу с потоками. PD>И не использукт дополнительной памяти ? И точно однопроходной ? Код его можно посмотреть ?
Там внутри стандартный LZW. Он использует небольшую дополнительную память (О(1)), но однопроходный. Код можешь посмотреть рефлектором.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, не странно. Дело в том. что, к примеру, выполнять операции матричной алгебры на компактированных матрицах как бы это выразиться ... не очень удобно . Перемножение еще туда-сюда, а вот нахождение, скажем, собственных значений и векторов (диагонализация) — лично я таких алгоритмов не знаю.
Знаешь. Только не даешь себе труда задуматься. PD>Там и без того N^3 по методу Якоби, а если еще в сжатом виде хранить — ждать будем до второго пришествия.
Это ты почему так решил? PD>А матрица именно разреженная, и очень сильно (говорю о задачах, которые решал во времена своих химических дел — расчет ИК-спектров, квантовая химия)
Спасибо за такую интересную дискуссию. Редко встречается столь идеальный собеседник VD>>Скорее всего матрица просто не самое эффективное представление данных. PD>Или нужно использовать хэш-таблицу, или еще что-то. А при этом и слгоритмы сериализации опменяются.
PD>Предложи для начала алгоритм диагонализации матрицы, представленных в виде хеш-таблицы
Гм. Вам там алгоритимист случайно не нужен? Похоже, все-таки программирование на плюсах некоторым людям ломает думательную часть в пользу кодописательной
Алгоритм, очевидно, будет точно таким же. Если, конечно, тим лидер или архитектор вовремя достал логарифмическую линейку и отбил пальцы битхакеру, который использовал для диагонализации матрицы ее внутреннее представление и пользовался указалелями, вычисленными по сложным формулам.
В таком случае есть некоторый алгоритм, который работает только с оператором [,] для доступа к элементам.
От того, что мы заменили реализацию этого оператора с вычисления указателя при помощи сложения и умножения на поиск в хеш-таблице, ничего не поменяется.
Это называется декомпозиция — разбиение сложной штуки на более простые. Я надеюсь, ты в курсе, что компиляторы плюсов уже лет десять как умеют получать для первого варианта матрицы точно такой же код, как и для обычного двумерного массива? Это позволяет смело пользоваться декомпозицией, не слишком заботясь о низкоуровневой производительности.
Теперь вернемся к нашей хеш-таблице. Приятной особенностью двумерного массива является время доступа за O(1) к любому элементу. Как ни странно, но нормально заполненная хеш-таблица имеет то же время порядка O(1)! Забавно, правда?
Может, нас спасет малый размер константы для массива? Увы. Павел, когда мы говорим о сильно разреженных матрицах, начинают играть большую роль эффекты второго порядка.
Вот смотри: допустим у нас матрица весит 10 мегабайт. Коэффициент заполнения — 5%. Т.е. ненулевых данных — всего 500kb. Моя машина оборудована L2 кэшем размером в 1024 kb.
Промах кэша — очень дорогая операция. Таким образом, интуиция подсказывает мне, что мы запросто можем выиграть в диагонализации разреженной матрицы за счет использования более компактного представления. У меня нет времени проверять это на практике. Но общая тенденция мне нравится — ты все время привлекаешь в качестве примеров только те ситуации, в которых ты неправ.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>Пример со сложным выводом в студию. Желательно реальный. Это должно быть легко — ведь в твоей практике такие выводы встречаются куда чаще, чем линейные, не так ли?
Пожалуйста, я его уже приводил. Матрица та же. Для каждой строки должно быть выведено среднее ее элементов, так как в зависимости от его значения эти строки будут потом вводиться или нет. Читать с диска строки, для которых m < некоторого K, не разрешается, они просто должны при вводе пропускаться.
Сложным этот пример не назвать, но сойдет.
Пример вполне реальный, я именно такое и писал, ну разве что не среднее там вычислялось, а немного посложнее.
Условие — никаких двухпроходных алгоритмов и памяти больше O(1).
Здравствуйте, Pavel Dvorkin, Вы писали: VD>>Хороший вопрос. Может его нужно было решать до того как ты начал использовать сериализацию?
PD>Уф, наконец-то первое здравое размышление в этой дискуссии.
Ты мне льстишь.
PD> Я же именно об этом и говорю. Я разве против сериализации, когда она оправдана алгоритмом?
Вот, по-моему, в этом и кроется ошибка. Она оправдана не алгоритмом, а решаемой задачей.
PD>Меня не сериализация беспокоит. Сама по себе она вполне законный метод, безусловно имеющий право на существование. Мне не нравится, когда ее применяют там, где совсем не надо.
Мне тоже. Но критерии у нас с тобой совсем разные.
PD> А тем более пытаются доказать, что применять ее все же стоит даже в тех случаях, когда она явно противоречит алгоритму (последнее утверждение есть непосредственно камешек в твой и Sinclair огороды)
Скорее это камешек брошенный вверх.
Ну, да это уже не конструктивно.
PD>В общем, не сотвори себе кумира из сериализации. Да и из всего другого тоже.
Мы с Синклером не творим себе кумиров из алгоритмов и абстракций. Мы просто, как нам кажется, правильно понимаем прицыпы выбора абстрации и значимость абстракции в процессе разработки. Жаль, что не удалось убидить тебя в верности нашего подхода.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А потому, что на него нужно лишнее время.
Хм. Я не заметил анализа времени в твоих рассужедениях. Зато заметил упоминание о том, что данные нужно хранить в файле.
Предлагаю следсвтенный эксперемент. Делашь тест сохраняющий данные в файл твоим способом и с использованием промежуточного MemoryStream. Затем сравниваем результаты и делаем выводы.
VD>>Хотя это конечно частный случай. Одако не вижу проблем в том, чтобы сформировать нужный список в памяти,
PD>Т.е использовать дополнительную память.
Временного буфера.
PD>А откуда ты знаешь, что незначителен ? В моей программе (там, правда, не разреженная тарица была, а нечто более сложное) суммарный размер выходных данных примерно 100 Мб. И хранить промежуточные данные мне негде.
Хм. 100 мегабайтное состояние объекта? Забавно.
Еще забавнее разговоры о разряженности в памяти и сжатии на диске при таких расскладах.
PD>Нет, не странно. Дело в том. что, к примеру, выполнять операции матричной алгебры на компактированных матрицах как бы это выразиться ... не очень удобно . Перемножение еще туда-сюда, а вот нахождение, скажем, собственных значений и векторов (диагонализация) — лично я таких алгоритмов не знаю.
И эти алгоритмы на огромных матрицах? Хм. Странно. Что-то ты не договоривашь.
В обом случае, матрицу можно эмулировать на хэш-таблицах елси что. Хотя конечно матричные вычисления вещь ресурсоемкая и могут быть проблемы. Ну, да как верно заметил Синклер матрицы прекрасно сериализуются без записи их длинны. Так что частный случай их размеров компенсируется частным же случаем простоты их сериализации.
PD>Предложи для начала алгоритм диагонализации матрицы, представленных в виде хеш-таблицы
Алгоритм то будет тот же самый (Ну, или это не ко мне. Я в матрицах не силен.). Только время доступа к ячейке больше. Но он может несколько компенсироваться за счет того, что хэш-таблица будет в кэше процессора, а огромная матрица будет вылетать за его пределы. Так что я бы все же поэксперементировал. Ведь сложность будет одинаковой — O(1). Разница только в константе.
Кстати, если матрица разряжена не равномерно, а значения сгруппированы вокруг некоторых диапазонов, например, лежат в неоторых строках, то возможно есть смысл заменить матрицу на вмложенные массивы. При этом нужно инициализировать только те массивы кторые содержат значения. Я использовал похожий подход в свомем оптимизаторе рассчета размеров символов. Смысл оптимизации таков. В юникоде 64 тысячи символов, но конкретный человек обычно пользуется только двумя страницами ASCII и страницей своей страны. Ну, туда-сюда может еще парочкой. Конечно с точки зрения эффективности самое лучше было бы создать массив размеров в char.MaxValue, но это слешиком большой массив. Шрифтов ведь может быть очень много. Тогда я сделал очень просто, я разбил шрифт на диапазоны по 256 (если не ошибаюсь) сивоволов и хранить каждый диапазон в подмассиве. Нужный диапзон рассчитывается путем получения остатка от деления. В итоге получился алгоритм со скоростью очень близкой к аналогичному использующему боьшой массив, но использующий значительно меньше памяти. Причем за счет лучшего использования кэша и отсутствия необходимости вычислять ширины символов не встречающихся в тексте этот варинт получился значительно более быстрым нежели лобовой вариант (проверено на тестах).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>От того, что мы заменили реализацию этого оператора с вычисления указателя при помощи сложения и умножения на поиск в хеш-таблице, ничего не поменяется. S>Это называется декомпозиция — разбиение сложной штуки на более простые. Я надеюсь, ты в курсе, что компиляторы плюсов уже лет десять как умеют получать для первого варианта матрицы точно такой же код, как и для обычного двумерного массива? Это позволяет смело пользоваться декомпозицией, не слишком заботясь о низкоуровневой производительности.
S>Теперь вернемся к нашей хеш-таблице. Приятной особенностью двумерного массива является время доступа за O(1) к любому элементу. Как ни странно, но нормально заполненная хеш-таблица имеет то же время порядка O(1)! Забавно, правда?
Еще как забавно! Настолько забавно, что мне даже неудобно объяснять.
Матрица является разреженной на входе. Как только начнется диагонализация, матрица разреженной быть перестанет. И во время этого процесса хранить ее надо целиком. К концу диагонализации, правда, матрица опять станет почти разреженной. Точнее, на диагонали будут собственные числа, а недиагональные элементы будут близки к нулю. Близки, но не равны — алгоритм Якоби приближенный, итерационный. И хранить эту матрицу придется до тех пор, пока мы эти собственные числа куда-нибудь не заберем, а матрицу уничтожим.
Если тебе угодно хранить целиком матрицу N*N в виде хеш-таблицы и для каждого обращения к ее элементу (внутри тройного цикла!) лазить в эту таблицу — бог тебе в помощь. А вообще даже интересно бы сравнить — во сколько раз можно здесь получить проигрыш. Я думаю (не утверждаю, а только думаю) — раз в 5 как минимум, а то и 10.
S>Это позволяет смело пользоваться декомпозицией,
Вот такая вот смелая декомпозиция получилась.
S>не слишком заботясь о низкоуровневой производительности.
Именно это я и вижу у тебя и VladD2. Не слишком заботясь о производительности (слово низкоуровневой здесь существенной роли не играет).. Именно это я и наблюдаю — с соответствующим результатом. Ты усвоил, что есть такой "паттерн" — хранение матрицы в виде хеш — таблицы (вполне применимый в определенных случаях) — и теперь, не думая, что из этого выйдет, суешь его туда, где он совершенно неприменим. Ты знаешь, что есть такая сериализация, и теперь упорно пытаешься ее сунуть и туда, где она годится как нельзя лучше, и туда, где она — пришей кобыле хвост.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, вариант с длинной плох еще тем, что в случае повреждения данных вместо распознования ошибки формата можно легко получить исключение выхода за пределы массива и т.п.
Да уж. Разумеется, при хранении -1 в конце ничего такого не произойдет — ни выхода за пределы массива, ни чтения за концом файла. Все будет замечательно.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Павел, ты начинаешь страдать нездоровой фигней.
Антон, такие аргументы гроша ломаногоь не стоят.
>Я тебе уже показал, что любая мало-мальски реалистичная задача решается без завышения требований к окружению.
S>Ну с чего это "чаще-нельзя"??? Павел, ты опасно заблуждаешься. Все как раз наоборот. Я вот в жизни не встречал еще необходимости делать fseek при сохранении.
Если ты не втечал, то это не аргумент. Другие встречали. Я , к примеру, в своей жизни ни разу не встречался с необходимостью посылать что-то в COM-port. Ну не программироваля вывод в COM, вот и все. Дает мне это основания утверждать, что это вообще никогда не требуется ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще как забавно! Настолько забавно, что мне даже неудобно объяснять. PD>Матрица является разреженной на входе. Как только начнется диагонализация, матрица разреженной быть перестанет. И во время этого процесса хранить ее надо целиком. К концу диагонализации, правда, матрица опять станет почти разреженной. Точнее, на диагонали будут собственные числа, а недиагональные элементы будут близки к нулю. Близки, но не равны — алгоритм Якоби приближенный, итерационный. И хранить эту матрицу придется до тех пор, пока мы эти собственные числа куда-нибудь не заберем, а матрицу уничтожим.
Прикольно. Я правильно понимаю, что этих близких к нулю можно смело убить, т.к. это погрешности алгоритма?
PD>Если тебе угодно хранить целиком матрицу N*N в виде хеш-таблицы и для каждого обращения к ее элементу (внутри тройного цикла!) лазить в эту таблицу — бог тебе в помощь. А вообще даже интересно бы сравнить — во сколько раз можно здесь получить проигрыш. Я думаю (не утверждаю, а только думаю) — раз в 5 как минимум, а то и 10.
Да, интересно. Будет время — сравним. Мне почему-то кажется, что для сильноразреженных матриц даже промежуточные результаты диагонализации содержат много нулевых элементов. S>>не слишком заботясь о низкоуровневой производительности.
PD>Именно это я и вижу у тебя и VladD2. Не слишком заботясь о производительности (слово низкоуровневой здесь существенной роли не играет).. Именно это я и наблюдаю — с соответствующим результатом. Ты усвоил, что есть такой "паттерн" — хранение матрицы в виде хеш — таблицы (вполне применимый в определенных случаях) — и теперь, не думая, что из этого выйдет, суешь его туда, где он совершенно неприменим.
Павел, ты опять бредишь. Я никакого паттерна не усваивал. Я просто критически отношусь к догмам. А ты как раз держишься за них со страшной силой. "У строки нету длины", "у матрицы длина должна быть в начале"... Мне очень забавно наблюдать за твоими попытками загнать меня в угол и высосать из пальца аргументы в пользу утверждений, которые ты просто никогда не проверял. PD>Ты знаешь, что есть такая сериализация, и теперь упорно пытаешься ее сунуть и туда, где она годится как нельзя лучше, и туда, где она — пришей кобыле хвост.
Я все еще жду от тебя примера персистенса, для которого не годится сериализация.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да уж. Разумеется, при хранении -1 в конце ничего такого не произойдет — ни выхода за пределы массива, ни чтения за концом файла. Все будет замечательно.
Сам алгоритм будет ориентирован на проверки целостности. А так тебя просто будет подмывать написать в стиле "ошибок быть не может".
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Маленькая поправка.
Слишком много у тебя поправочек. Чуть что новая. Как-то настораживает.
PD>Исходная матрица 1000*1000. Размер 4 Мб. PD>Ненулевых элементов 5%. Их объем при хранении 1000*1000*0.05 * 3 * 4 = 600 Кб. Можно и меньше, если более оптимальным способом хранить
Ой, ё! 4 метра! Эот же как мы сильно пострадаем!
А кстати, как? Я вот 3.5 метровый текстовый файл в своем редакторе читаю с подсветкой синтаксиса и переносом строк. Не сказал, бы что уж так это критично. А уж банальное бинарное чтение вообще никто не заметит.
Что до объемов занимаемых на диске... Ну, в памяти же ты жертвушь этими 4 метрами? Если файлов еденицы, то можно наплевать и забыть. Диски сплошь много-гигабайтные. 4 метра никто не замитит.
PD>Как говорят в Одессе, две большие разницы. 4 Мб и 600 Кб. Если тебе это до лампочки — на здоровье.
И в чем разница? Ну, какая нафиг пользователю разница? Если надо будет передать по сети, то можно банально сжать зипом.
PD>И зачем это люди архиваторы используют ? Хранили бы файлы как есть. Современной системе это до лампочки!
Вот за тем и используют архиваторы, чтобы не заниматься частными оптимизациями по каждому поводу. А если бы люди мыслили все как ты, то вместо HTML/XML мы сейчас бы имели страшную бинарную фигню. Кстати, подобные предложения на этом форуме уже были.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Я просто критически отношусь к догмам. А ты как раз держишься за них со страшной силой. "У строки нету длины", "у матрицы длина должна быть в начале"
У меня сегодня бессоница случилась. Проснулся часов в 6 и уснуть не смог. От нечего делать стал вспоминать эту дискуссию и обнаружил любопытный момент.
Перечти то, что ты написал выше.
Итак, я придерживаюсь двух догм. А ты не заметил, что эти две догмы взаимно исключают друг друга ? Ведь речь-то , по существу, об одном и том же идет — надо ли хранить длину ? Только в одном случае речь идет о строке символов, а в другом — о строке троек (i,j,val).
Придерживаться двух взаимоисключающих догм одновременно — это уж больно круто. Или же в этом нет ничего особенного — но тогда надо признать, что это не догмы.
Кстати, и ты здесь поворот на 180 градусов совершил. Для текстовых строк ты с жаром утверждал, что они просто обязаны хранить в себе длину, а вариант без длины, но с терминатором в конце (ASCIIZ) есть полный отстой и анахронизм. Теперь же вдруг выяснилось, что хранить с терминатором в конце — это правильно, а с длиной — нехорошо. Правда, речь идет не о символах , а о некоторых тройках чисел. Честно говоря, принципиальной разницы не вижу.
Заметь, я тебя вовсе не упрекаю в том, что ты в одном случае придерживаешься одной точки зрения, а в другом — другой. Более того, это правильно. Если ты в состоянии серьезно аргументировать, почему в одном случае надо так, а в другом — наоборот, то именно так и надо делать.
Что же касается меня, то все не просто, а очень просто. Для меня приемлемы и тот, и другой варианты. И для строк символов, и для строк троек. Для текстовых строк я вполне принимаю ситуацию, когда лучше не вычислять ее длину каждый раз, а хранить отдельно (а может, и не только длину, может, еще и хеш-значение), равно как и утверждаю, что бывают ситуации, когда не стоит тратить память на хранение этих длин, а вместо этого надо их вычислять каждый раз. То же самое и для этих троек — в одном случае стоит хранить их количество (длину), в другом — терминатора хватит.
А если к этому вопросу подойти чуть с более общих позиций, то он и вообще прост до банальности становится.
Есть некие данные, сильно или слабо структурированные. Их надо сохранить в файле. В одном случае достаточно сохранить их "как есть", так как структурированность их слабая (данные однородные). В другом случае данные неоднородные, а поэтому требуется завести некий управляющий блок, который и будет их структуру описывать, чтобы потом их прочитать можно было и структуру восстановить.Блок этот может быть очень простым (число троек в моем примере) или более сложным . Обычно его помещают в начало файла, из-за чего вся проблема и возникает. Можно, конечно, его в конец файла поместить, тогда частично проблема будет снята, но — не поймут
И вот если без этого блока обойтись нельзя, а формирование его возможно только путем просмотра (возможно, с дополнительной обработкой) сохраняемых данных, то у нас есть следующие варианты
1. Отвести в файле место для этого блока. Сохранить данные, проведя по ходу действия их обработку, вычислив по ходу действия поля блока. Вернуться в файле назад и записать блок. ИМХО самое разумное решение.
2. Двухпроходной алгоритм. Просмотреть данные, проведя по ходу действия их обработку, если надо и вычислив по ходу действия поля блока. Записать блок. Повторить просмотр данных с обработкой, записывая их при этом.
Недостаток — 2 прохода, повторные действия.
3. То же что и 2, но на первом проходе обработанные данные сохраняются где-то. На втором проходе они и записываются.
Недостаток — дополнительный расход памяти.
А если без этого блока можно обойтись, то все это не нужно, и можно просто записать данные подряд, а в конце терминатор пристроить или вообще ничего не писать, если эти данные в конце файла или же в файле кроме этих данных ничего нет.
Вот и все.
Примеры — пожалуйста.
1. Есть двумерная матрица цветов, размер ее известен. Надо сохранить ее в BMP-файл, 8 bpp. В зависимости от того, даст ли это эффект, сохранять надо ли в несжатом (BI_RGB), либо в сжатом (BI_RLE8) формате. Заголовок BMP-файла содержит 2 поля — BITMAPFILEHEADER.bfSize и BITMAPINFOHEADER.biCompression, которые зависят от того, будет ли сжатие или нет. Определить, будет ли сжатие можно только просмотром матрицы. Совершенно разумно провести этот просмотр, формируя при этом по ходу действия каждую строку в сжатом виде и выводя ее (либо же выводя исходную строку как есть). По окончании этого процесса станет ясным, использовалось сжатие или нет, какова длина получившегося файла, и байты карты будут уже на диске. Остается заполнить два поля в заголовке, вернуться в начало файла и записать заголовок.
2. PE-формат. Там, как ты помнишь, полно вcяких RVA в заголовках. Заполнить их значения можно будет после того, как фактически весь PE-файл уже собран, так как для этого надо знать размеры секций, а их не определишь, пока весь граф не построишь. Не будешь же ты предлагать строить граф дважды — первый раз, чтобы определить размеры секций , а второй — для того, чтобы сами секции построить. Естественно, я не знаю, как линкер устроен внутри себя, действительно ли он однопроходной (там и другие факторы могут быть), но то, что ради этого никто лишний проход делать не будет — в этом я уверен.
Честно говоря, даже странно тебе это объяснять. Ты прекрасно это понимаешь и сам, не могу допустить, что не понимаешь. И доведись тебе линкер писать — разумно бы и сделал, не сомневаюсь. Просто заклинило тебя тут — доказать, что алгоритм последовательного выкладывания такой уж хороший — вот ты и начал его совать туда, где он совсем ни к чему.
А в самой идее именно сериализации (как алгоритма последовательного выкладывания) — ничего плохого нет. И применять его вполне можно. И даже нужно, так как он самый простой, а я твердо убежден в правоте принципа KISS. Только при одном условии — когда он уместен. А когда неуместен — не надо насиловать структуры данных, а надо просто иной алгоритм применить. Много их на свете — хороших и разных
S>Я все еще жду от тебя примера персистенса, для которого не годится сериализация.
Ну если уж тебе так жизненно он нужен — расскажи, как будешь сериализовать мою матрицу цветов в BMP-файл с RLE кодированием.
Здравствуйте, VladD2, Вы писали:
VD>И, кстати, натянутость самой ситуации снова настораживает. Значит при хранинии данных в памяти (которая как извесно примерно на 3 порядка дароже) ты выбирашь плоские массивы, а при хранении на диске вдрг слезно озаботился компактностью. Странно это.
См.мое письмо к Sinclair, где я объяснил суть проблемы
VD>Скорее всего матрица просто не самое эффективное представление данных. Или нужно использовать хэш-таблицу, или еще что-то. А при этом и слгоритмы сериализации опменяются.
Здравствуйте, denis_krg, Вы писали:
_>На самом деле в управляемых средах сериализацию ввели не для того, чтобы сохранять что-то в файлах, а для Remote-интерфейсов. А в файлы, которые есть долговременные хранилища — приходится писать сериализацию ручками, чтобы быть независимыми от версии. Причем крайне желателен текстовый формат (типа XML), чтобы не зависить не только от структуры отдельного класса, но и от их совокупности (грубо говоря есть Клиент, у него Адреса, в адресе еще что-то и т.д. и т.п.). Так что стандартная сериализация она не в файл, а по сети )))
О! Вот с этим готов полностью согласиться.
И, конечно, дело не в управляемых средах или именно Remote интерфейсах, а тем более в XML-формате. Дело в том, что в этих задачах предполагается именно последовательная передача данных. Либо устройство иное не поддерживает, либо это по иным причинам требуется. И тогда, конечно, именно сериализацию как алгортим надо использовать.
Но зачем тогда адепты ее упорно пытаются ее загнать туда, где она совсем не нужна ?
Здравствуйте, VladD2, Вы писали:
PD>>Уф, наконец-то первое здравое размышление в этой дискуссии.
VD>Ты мне льстишь.
Ну что ты. Я просто рад, что и у тебя бывают моменты, когда здравый смысл торжествует над принципами
PD>> Я же именно об этом и говорю. Я разве против сериализации, когда она оправдана алгоритмом?
VD>Вот, по-моему, в этом и кроется ошибка. Она оправдана не алгоритмом, а решаемой задачей.
Трудно сказать. Зачастую это лишь маленький такой кусочек задачи. Например, в той же MFC (понимаю, что она тебе не близка, но говорю о том. что знаю) сериализация предлагается для сохранения документа в файл. А это не задача, это просто штатная фича почти любой программы. К счастью, там она элементарно обходится, так что каждый волен выбирать, сериализовать ему или нет.
А вот если именно задача по своей сути предполагает сериализацию — я на 200% за. Глупо было бы выступать против алгоритма, который напрашивается самой задачей.
PD>>Меня не сериализация беспокоит. Сама по себе она вполне законный метод, безусловно имеющий право на существование. Мне не нравится, когда ее применяют там, где совсем не надо.
VD>Мне тоже. Но критерии у нас с тобой совсем разные.
Да, это уже давно ясно. Тут мы не договоримся.
PD>> А тем более пытаются доказать, что применять ее все же стоит даже в тех случаях, когда она явно противоречит алгоритму (последнее утверждение есть непосредственно камешек в твой и Sinclair огороды)
VD>Скорее это камешек брошенный вверх.
Под углом к горизонту и с предполагаемым местом приземления в огороде
Здравствуйте, VladD2, Вы писали:
VD>Предлагаю следсвтенный эксперемент. Делашь тест сохраняющий данные в файл твоим способом и с использованием промежуточного MemoryStream. Затем сравниваем результаты и делаем выводы.
А что сравнивать-то будем ?
Я ведь четкие требования предложил . Напомню.
1. Результат — файл с числом троек в начале и потом тройками
2. Дополнительная память — O(1)
3. Двухпроходной алгоритм не рассматривается.
А ты предагаешь дополнительную память использовать (MemoryStream). Не вижу смысла в сравнении. Используя дополнительную память, можно многие алгоритмы улучшить по какому-то критерию.
Вот если можешь всем моим требованиям удовлетворить — пожалуйста. Впрочем, можешь и сам эти сравнения тогда провести. Один вариант — с сериализацией, другой — с BinaryWriter, например.
PD>>Т.е использовать дополнительную память.
VD>Временного буфера.
У нас все временное. И программа работает не вечно, и мы сами не вечны.
PD>>А откуда ты знаешь, что незначителен ? В моей программе (там, правда, не разреженная тарица была, а нечто более сложное) суммарный размер выходных данных примерно 100 Мб. И хранить промежуточные данные мне негде.
VD>Хм. 100 мегабайтное состояние объекта? Забавно.
Забавно. Еще как. А что прикажете делать ? Конечно, надо бы его в БД хранить, да вот вся беда в том, что это и есть моя собственная квази- БД. Я же ясно написал — речь уже не о матрице идет, а совсем о другом.
VD>Еще забавнее разговоры о разряженности в памяти и сжатии на диске при таких расскладах.
А тут уже никакой разреженности в памяти и не было. Тут прошло шло формирование огромного блока данных с записью его на диск. И при этом в файле постоянно делались перемещения назад для заполнения управляющих блоков, которые заполнить можно было только тогда, когда сами данные уже обработаны и записаны. Кстати, занимал этот процесс 5 часов времени.
PD>>Предложи для начала алгоритм диагонализации матрицы, представленных в виде хеш-таблицы
VD>Алгоритм то будет тот же самый (Ну, или это не ко мне. Я в матрицах не силен.). Только время доступа к ячейке больше.
Вот тут и корень наших разногласий. С высказыванием "Алгоритм то будет тот же самый" — согласен на 100%. Потому как я не великий математик и предложить собственный алгоритм диагонализации не смогу. Так что твоя любимая абстракция здесь блестяще работает. А вот имплементация этой абстракции будет жуткой. Потому что в хеш-таблице придется хранить уже не разреженную матрицу, а всю матрицу, так как она после первой же итерации перестанет быть разреженной (к тому же матрица вещественная). И время работы я оцениваю в 5-10 раз больше.
>Но он может несколько компенсироваться за счет того, что хэш-таблица будет в кэше процессора, а огромная матрица будет вылетать за его пределы.
Насколько я понимаю, если всю матрицу хранить не в виде двумерного массива, а в хеш-таблице, памяти меньше не понадобится. Скорее больше
>Так что я бы все же поэксперементировал. Ведь сложность будет одинаковой — O(1). Разница только в константе.
Чудно! Великолепно! Именно! Вот здесь вся твоя позиция и заложена.
Разница только в константе! Абсолютно согласен!
Алгоритм Якоби имеет O(N^3). Если мы храним матрицу как массив или как хеш-таблицу — от этого он N^3 быть не перестанет и в N^4 не превратится (предполагая, что хеш-таблица есть O(1))
Беда только в том, что эта констатна сильно возрастет. Вот это ты и не хочешь принимать во внимание. А мне не все равно, 2N^3 или 20N^3. Асимптотика — та же самая. А в реальности — работает в 10 раз медленнее.
Вот и все. Для тебя это мелочь. Потому что на уровне абстракций ничего не изменилось. а на уровень реализации ты переходить не хочешь.
В этои и корень всех наших разногласий. Все остальное вторично.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>И зачем это люди архиваторы используют ? Хранили бы файлы как есть. Современной системе это до лампочки! S>Вот кстати если использовать архиватор, то он сам выкинет все эти нули. А знаешь, в чем прелесть? В том, что зип сожмет и матрицу из всех единиц. А твой алгоритм разбарабанит ее вдвое. При этом для скармливания ее зипу все равно придется сначала выделить буфер размером в 8mb, потому что тебе очень хочется вернуться в начало.
В огороде бузина, а в Киеве дядька. Естественно, архиватор выкинет эти нули и сожмет все как надо. Только при этом не впрограмму придется его код встроить, так как ей данные нужны, а не архив. Данные в формате троек она легко прочитает, а деархиватор в нее встраиваь совсем незачем.
А про архиватор я совме по другому поводу говорил.
V>Ну, и что если у меня файл будет не 100 байт, а килобаймт? Современной системе это до лампочки.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В огороде бузина, а в Киеве дядька. Естественно, архиватор выкинет эти нули и сожмет все как надо. Только при этом не впрограмму придется его код встроить, так как ей данные нужны, а не архив. Данные в формате троек она легко прочитает, а деархиватор в нее встраиваь совсем незачем.
Я правильно понимаю, что ты просто никогда не пользовался архиватором программно, и полагал, что это специальный тул для приведения файлов в нечитаемый вид? Ты же такой борец за размер — почему ты не рассмотрел никакую компрессию матрицы при записи? Я тебя уверяю — для разреженной матрицы отличный результат дал бы банальный RLE. А LZW мог бы и лучше, при выполнении определенных условий. Почему ты не рассмотрел ни того ни другого?
Кстати, вот авторы GIF почему-то решили, что лучше встроить LZW прямо в формат, вместо требования пережимать записанный на диск файл внешней программой. Так что это вовсе не я изобрел применять сжатие при хранении. А джавные пакеты распространяются в пожатом с помощью ZIP виде. И встроенный класслоадер поддерживает декомпрессию.
В общем, Павел, результат примерно такой: сейчас не рулят ни догмы, ни интуиция. Рулит умение применять готовые алгоритмы для построения своего решения. И ключом к успеху служит хорошее понимание границ применимости этих алгоритмов.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В огороде бузина, а в Киеве дядька. Естественно, архиватор выкинет эти нули и сожмет все как надо. Только при этом не впрограмму придется его код встроить, так как ей данные нужны, а не архив. Данные в формате троек она легко прочитает, а деархиватор в нее встраиваь совсем незачем.
В .NET тебе и встраивать ничего не надо Framework 2.0 есть пространство имен System.IO.Compression там есть и архивватор и разархиватор.
Редко.
>А как ты думаешь, в каком месте файла расположены теги жанра, категории и прочее?
Никак не думаю. Надо будет — поищу описание формата файла.
>Вот ты употребил чудесную фразу "Обычно его помещают в начало файла, из-за чего вся проблема и возникает". Совершенно ты на сто процентов прав! Именно из-за этого проблема и возникает. В голове у тех, кто пытается все положить в начало. В том числе и то, что в начале никак не нужно. Просто из-за боязни, что "не поймут". Я даже слово подходящее для такого подобрать не могу. Здравый смысл рулит!
Передергивать не надо. Говоря "вся проблема и возникает" я имел в виду "у тех, кто хочет записать это последовательно". Никаких других проблем с тем же BMP до сих пор ни у кого не возникало.
S>Так, что-то я не понимаю. Флаг вроде один, а ты собираешься на ходу переключаться для каждой строки.
Это невозможно. Ты сначала должен выбрать какой-то один вариант. В случае, если он оказался неудачным, тебе придется начать процесс заново, переписав не только хидер, но и сами данные, пережав их используя выбранный алгоритм. Или я что-то неправильно понял?
Сорри, здесь ошибся. Я почему-то считал, что можно смешивать сжатые и несжатые линии и там есть какой-то тег, указывающий что эта линия не сжата. Отложилось такое в памяти, видимо, из какого-то другого формата. Но сути это не меняет.
S>Насчет bfSize ты конечно же прав. Это как раз случай, когда архитектура победила здравый смысл. В итоге я не могу отдавать битмэп из http-хэндлера без предварительной записи его в буфер. Так это не сериализация плохая! Это RIFF — устаревший, плохой и неудобный формат. Но не надо путать формат BMP и задачу представления изображения. Формат — всего лишь одно из решений этой задачи. И особенно удачным я его назвать не могу.
Твое дело. Но и аргументацию — мне формат не нравится, потому что я не мону это вывести последовательно — не принимаю. Я — могу (не последовательно). Никаких проблем этот формат не вызывает у меня.
PD>>2. PE-формат. Там, как ты помнишь, полно вcяких RVA в заголовках. Заполнить их значения можно будет после того, как фактически весь PE-файл уже собран, так как для этого надо знать размеры секций, а их не определишь, пока весь граф не построишь. Не будешь же ты предлагать строить граф дважды — первый раз, чтобы определить размеры секций , а второй — для того, чтобы сами секции построить. Естественно, я не знаю, как линкер устроен внутри себя, действительно ли он однопроходной (там и другие факторы могут быть), но то, что ради этого никто лишний проход делать не будет — в этом я уверен. S>Я тоже не в курсе, как работает линкер. К тому же их много разных. Современные скорее всего собирают весь файл в памяти. Кстати, насколько я помню, PE-формат проектировался еще для тех времен, когда важна была возможность посегментной загрузки.
Сегментов в PE отроду не было. Если, конечно, ты понимаешь под сегментов нечто в смысле сегмент:смещение от x86. Если нет — что тогда ты понимаешь под сегментом ? Одно могу сказать с уверенностью — сегментов там нет. Есть секции. Но это просто куски в плоском пространстве.
>Я ничего не путаю? Если нет, то все правильно — я уже в третий раз могу сказать, что сериализация — не для случаев неполного чтения/записи.
В общем, логика простая. Те форматы, которые тебе не нравятся — ущербны по определению.
PD>>Честно говоря, даже странно тебе это объяснять. Ты прекрасно это понимаешь и сам, не могу допустить, что не понимаешь. И доведись тебе линкер писать — разумно бы и сделал, не сомневаюсь. Просто заклинило тебя тут — доказать, что алгоритм последовательного выкладывания такой уж хороший — вот ты и начал его совать туда, где он совсем ни к чему. S>Павел, я пока никуда этот алгоритм не совал. Ты меня ни с кем не путаешь?
Нет. Именно ты и предложил сериализовать с -1 там где это не нужно.
S>Тебе было интересно, каковы критерии применимости этого алгоритма — я пытаюсь их тебе объяснить. Ты с завидным упорством не видишь этих границ, и игнорируешь мои аргументы.
Скорее это именно к тебе применимо — в плане сериализации. Я пытаюсь тебе объяснить, что притягивать ее не стоит за уши. Ты именно все это игонорируешь, а упорно доказываешь. что все , что под нее не подходит — есть неправильный формат и т.д.
>Ты приводишь в качестве примеров задачи, где сериализация отлично подходит. Я ясно вижу, в каких местах ты апеллируешь не к задаче, а к решению. Которое вовсе не является единственным.
Безусловно не явяляется единственным. Я вообще в единственные решения в нашей сфере плохо верю (кроме тривиальных случаев). Оно мне кажется оптимальным
S>Я вот не буду цепляться за решение, оказавшееся неудачным. Не подходит матрица на хэш-таблице для алгоритма Якоби — и хеш с ней. Вернемся к массиву.
Естественно.И к вопросу о том , как его хранить в файле и как выводить. Будет сказка про белого бычка.
S>Но лучше все-таки подняться на шаг выше, и понять, что не старик Якоби наше начальство. Все наоборот — это мы привлекли его для выполнения задачи поиска собственных значений. И если он нас перестанет устраивать, то первым вылетит на помойку, а вместо него мы возьмем более быстрый алгоритм для трехдиагональных матриц. И совершенно случайно может оказаться, что этот алгоритм не загаживает разреженную матрицу значениями, а значит для него хеш имеет шанс выиграть за счет попадания в L2/L1 cache.
Не фантазируй. У меня матрица не трехдиагональная, и я вовсе не знаю, может ли она быть к этому виду приведена, и если да — сколько это стоит по времени и памяти. А алгоритм Якоби — один из двух основных (есть еще алгоритм Хаусхольдера, он лучше по времени, N^2log(N), но не столь устойчив, бывают проблемы. Других в те времена, когда я этим занимался, в квантовой химии не было. Если бы возможность сократить объем хранимых данных была, ей бы тогда обязательно воспользовались — память была на вес золота.
А во-вторых, он нас вполне устраивает. Не надо только к нему ненужные примочки пристраивать в виде хеш-фокусов. Матрица хранится на диске, нули не хранятся, при вводе создается и заполняется матрица, диагонализируется и берется результат. Можно ли это улучшить — вопрос к математикам, а не ко мне.
S>Но до всех этих мыслей, Павел, невозможно дойти, если сразу начать рассуждать в терминах какого-то специфического решения. В реальном проекте окажется, что кто-то будет реализовывать обратный fseek в потоке, который его раньше не поддерживал,
Не будет он реализовывать обратный fseek в потоке, который его раньше не поддерживал. Потому что не будет никакого потока. Будет файл (FILE*, file of byte Паскаля, BinaryWriter и т.д.). Если же этот файл перестанет поддерживать fseek, (забыл как в Паскале), Seek) — подам в отставку и с горя утоплюсь.
>только потому, что Павел Дворкин не моргнув глазом сказал "а без этого невозможно эффективно записывать разреженную матрицу". Ок, не все достаточно дотошны, чтобы копнуть поглубже и посмотреть, чем вызвана такая уж необходимость в fseek.
Необходимость в fseek просто не обсуждается. Если есть файл прямого доступа (FILE*, не в текстовом режиме), то возможность в нем fseek обеспечивается по определению.
S>Совершенно согласен. Но ты до сих пор не сумел даже наметить критерия этой применимости. Твоя интуиция, которой ты пользуешься, как мы имели шанс убедиться, промахивается в половине случаев.
Еще раз — лучше в таких случаях говорить ИМХО. Потому как если тебе кажется, что ты в этом убедился — это означает не то, что есть на самом деле, а лишь то, о чем ты говоришь, т.е ты в этом убедился. Убедил себя
>Лучше бросай монету Или все же попробуй сформулировать правило, которое однозначно определяет, подходит ли сериализация для решения определенной задачи.
Нет. Я уже сто раз говорил — я действую от задачи, а не от паттерна. Вот задача будет — тогда и решу, стоит ли там сериализовать или нет. В текстовый файл вывод — буду. В BMP — не буду. А общие правила предложи VladD2 формулировать или сам этим займись.
S>Нет, Павел, это он тебе жизненно нужен. Я-то как раз знаю, где что применимо, а где что нет.
Я тоже. Мы оба знаем. Нет проблем
PD>>- расскажи, как будешь сериализовать мою матрицу цветов в BMP-файл с RLE кодированием. S>Ты знаешь, все зависит от задачи. Если кровь из носу нужно писать именно BMP файл, то можно и fseek-ом воспользоваться. Отдавая себе отчет, конечно, в том, что ни для чего другого эта методика не подходит. А если я картинку между вебсервисами буду передавать, и речь будет идти о полиграфических размерах типа 8000*6000, то я потрачу куда больше времени на проектирование рабочего решения.
Если ты решил ее в несжатом виде или даже RLE передавать при таких размерах по сети — да поможет тебе бог!
S>Понимаешь, нет никакого BMP. Это фикция, плод больного воображения людей, которые решали одну узкоспецифическую задачу.
"Так дьявола тоже нет ? Что же у вас, чего ни хватишься, ничего нет ?" (М.Булгаков, Мастер и Маргарита, цитирую по памяти)
"Но умоляю Вас, на прощание поверьте, что дьявол все же существует. На этот счет есть самое серьезное, последнее жоказательство, и оно Вам сейчас будет предъявлено " (оттуда же).
Так что поверь мне на слово, что BMP все же существует. Если не веришь — давай свой e-mail, пришлю. Размера 8000*6000. Специально сделаю, своей программой выведу в файл. Без сериализации.
S>Вот встань у меня задача сделать систему совместного редактирования изображений сверхбольших размеров — никаким BMP там даже рядом не запахнет. Потому, что его устройство плохо подходит для требований задачи.
Кроме него, для решения этой задачи не подходит масса других форматов. Они, однако, вполне подходят для других задач. А тот формат, который ты выберешь (надеюсь, наилучший для этой задачи) не подойдет для других задач. Ну и что ?
Если бы был формат, который для всех задач наилуший, остальные форматы давно бы померли.
S>А если мне надо в винде иконку в трей засунуть, то я не стану кровь из носу заниматься оптимизациями на уровне fseek. Там всех данных меньше, чем размер страницы файловой системы!
Именно так. Поэтому в одном случае я буду сериализовать, в другом -писать от хвоста к началу , в третьем будут MMF, а в четвертом — пока не знаю.
На этом должен прекратить дискуссию,так как новый проект начинается и времени нет. Будет ли в нем сериализация — пока не знаю .
Естественно, за тобой последнее слово в этой дискуссии, раз я ее прекращаю. Если, конечно, хочешь.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Я правильно понимаю, что ты просто никогда не пользовался архиватором программно, и полагал, что это специальный тул для приведения файлов в нечитаемый вид?
Я сам писал код для PCX. Давно, правда.
>Ты же такой борец за размер — почему ты не рассмотрел никакую компрессию матрицы при записи?
Позволю напомнить тебе, что разреженная матрица была приведена мной не как самостоятельный пример, а как пример того, что при именно ее записи и именно в таком виде метод последовательной записи плохо годится. Если же мне реально понадобится хранить разреженную матрицу — буду действовать в зависимости от задачи.
S>Кстати, вот авторы GIF почему-то решили, что лучше встроить LZW прямо в формат, вместо требования пережимать записанный на диск файл внешней программой. Так что это вовсе не я изобрел применять сжатие при хранении. А джавные пакеты распространяются в пожатом с помощью ZIP виде. И встроенный класслоадер поддерживает декомпрессию.
Еще раз — не уходи в сторону. Я привел вывод разреженной матрицы как пример для демонстрации, когда сериализация не работает. И только. Я не имел цели рассматривать все способы хранения разреженных матриц и сравнивать их..
S>В общем, Павел, результат примерно такой: сейчас не рулят ни догмы, ни интуиция. Рулит умение применять готовые алгоритмы для построения своего решения. И ключом к успеху служит хорошее понимание границ применимости этих алгоритмов.
Результат таков — ты пытаешься переключиться на совсем другую тему. Ее у меня ни времени, ни желания обсуждать нет.
Binary Serialization for the DataSet
VD>This new option enables a DataSet and a DataTable to be serialized in binary format when using binary transports over remoting. In most cases this will result great performance improvements and a noticeable reduction in both memory and CPU usage when using DataSet/DataTable objects in applications that use remoting to connect to different tiers.
Здравствуйте, Sinclair, Вы писали:
S>Вот и всех делов. Здорово, правда? Никакой лишней памяти, никакого лишнего времени, и никакого требования поддерживать произвольный доступ.
Я бы еще предложил записывать в начале размер разряженной матрицы, а затем и ее саму, пожатую RLE.
... << RSDN@Home 1.2.0 alpha rev. 642 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Вся кастомная сериализация в .NET в итоге сводится к классу SerializationInfo. Соотв. заполнять ты ее можешь любым алгоритмом. Ползанья по потоку там, естественно, нету, поскольку основная задача штатной сериализации — передача информации между доменами (процессами, машинами), а там возможности позиционирования нет.
Вот это я и хотел узнать. Итак, возможности позиционирования нет и там.
VD>>>Про ООП узнать мало. Еще нужно вжиться в него.
PD>>Слушай, хватит. Я про ООП узнал еще во время Turbo Pascal 5.5.
AVK>Я тоже. И что?
Не знаю. Спроси VladD2. Он же начал меня в непонимании идей ООП обвинять.
AVK>То, что ты описал называется оптимизацией. Которая почти всегда ухудшает структуру программы. Но оптимизации делают обычно, когда точно известны узкие места. Делать ее заранее и везде — прямой путь к убийству мало мальски крупного проекта. Именно об этом и пытается тебе сказать Влад.
Я уже на эту тему выступал осенью. Не хочу возвращаться к ней.
AVK>Теперь от лирики перейдем к конкретике. Примеряя твои слова на вышесказанное у меня возникает масса вопросов. Вот некоторые из них: AVK>1) Предлагая одновременно с абстракциями думать о реализации, ты увеличиваешь количество сущностей на одном уровне.
На разных уровнях. Я об этом писал в письме к Владу — переключение между уровнями.
[Остальная часть этого замечания skipped в связи с этим возражением.]
AVK>2) В современном программировании, даже в том стиле, который ты предлагаешь, мы всегда имеем слои абстракции и сверху, и, что совсем не удивительно, снизу. Возвращаясь к твоему примеру — файл конечно существенно более узкое понятие, нежели поток, но тем не менее это тоже абстракция и даже не самая последняя в ряду.
Абстракция — да. Но я с ними не борюсь вовсе. Почему более узкая — не понимаю. ИМХО просто иная. Дерево не есть более узкая абстракция, чем массив, это просто разные вещи. А файл допускает операции, которых нет в потоке, поэтому его можно считать иной абстракцией, чем поток, но не более узкой . Впрочем, это мелочи.
>Теперь собственно вопрос — в какой момент нам следует прекратить думать о реализации нижележащих абстракций?
На том уровне, на котором изменение в реализации перестает влиять на свойства программы (быстродействие, память и т.д.) Или когда мы попадаем на уровень, который нам неподвластен. Как только один из этих уровней достигнут — стоп. Дальше думать не о чем — думай не думай, а ничего не изменится.
>Почему я, при создании сериализации, должен думать о файле, но не должен думать о кластерной структуре ФС?
Потому что ты не выбираешь ФС. Это тебе не подвластно в данной ситуации. По крайней мере пока мы под Windows и нельзя требовать, чтобы там была FAT, а не NTFS, (условно предполагая, что она быстрее). То, что не подвластно — не обсуждается, это просто дано.
>Или должен. Тогда когда не должен? Об абстрактной модели контроллера IDE должен?
Не должен. Ни к к какому улучшению это не приведет. А если залача такова, что приведет и можно выбирать — должен. Но тогда, по-видимому, твоя программа есть драйвер этого контроллера (устройства) и странно бы не думать о его модели, программируя драйвер.
(В скобках. А это не демагогия ? При чем тут контроллер ? Какую роль он может играть в процессе проектирования и разработки обычного ПО (за исключением такого ПО, которое именно на свойства контроллера завязано ) ? Чем мне помогут мысли о контроллере, если я никак на его выбор повлиять не могу ? При чем тут ФС, если я ее тоже выбирать не могу! )
PD>> Ведь не воздушный замок же я строю! Почему я должен от свойств материала отрешаться ? Ведь рухнуть же может здание, не выдержат они и будет ЧП. А абстрактно — колонны вещь замечательная. Красиво и приятно. А потом выяснится вдруг — крышу не держат. Примеры напомнить ?
AVK>Я тебя умоляю — не стоит делать далеко идущие выводы из аналогий. Строительство это далеко не то же самое, что создание программ и тому есть масса причин.
Все аналогии хромают. Эта тоже. Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
PD>>А если в ходе этого анализа я выясню, что эффективной паттерна "Сериализация". реализации в данном случае не существует, то я начну все сначала.
AVK>Это нормально. Называется рефакторинг. Ничего страшного в нем нет.
Вполне согласен. Я же об этом говорил — откажусь от нее (кстати, если уж на то пошло, в реальной работе я сначала именно ее и попробую, зачем мне лишние сложности ?) и задействую иное. А другие пытаются ее изо всех сил все же запихнуть, доказывая, что она годится там, где она не годится. В этом все различие.
PD>>Нет. Я просто одновременно работаю на обоих уровнях.
AVK>Знаешь поговорку о погоне за двумя зайцами?
Знаю. А вот ты фразу помнишь — "И таким образом мы убъем здесь двух зайцев сразу."? Народная мудрость, она, знаешь многовариантна
PD>>Ты ведь утверждаешь, что об абстракции можно говорить, не вдаваясь в детали реализации. Так до того, как код написан и быстродействие его померяно, откуда тебе знать, годится она или нет ?
AVK>Золотые слова. Этого не знает Влад. Более того — этого и ты не знаешь.
Нет. Это он не знает (точнее, делает вид, что не хочет знать). Я — знаю. Не всегда и не везде. Могу ошибиться, с кем не бывает. Но кое-что знаю точно. На основании своего прежнего опыта. На основании доступной мне информации. Что почем (в плане времени) — я многое знаю. И в плане памяти тоже. И если я знаю, во что мне выльется копирование половины (в среднем ) массива при вставке в него элемента в любую позицию, то не будет у меня здесь абстракции массив, а будет абстракция бинарное дерево. Потому что временную зависимость алгоритма вставки я знаю для обоих. И хотя массив как структура данных (абстракция) меня, допустим, вполне устраивает (она там по смыслу задачи самая подходящая), я знаю, что реализации ее без O(N) хоть в какой-то одной операции не существует. А для дерева — существует. И поэтому выберу дерево, хотя в нем нет индексации (будем так считать) и оно, вообще-то, хуже в абстрактную схему программы, на высоком уровне, укладывается. Более того, не очень оно там уместно, прямо скажем. А выберу его. Из-за реализации.
PD>>Поточнее , пожалуйста. Если ты имеешь в виду, что маппер не слишком эффективно из строки БД формирует экземпляр класса (в ОП), то я с этим согласен. Там на каждом шагу Reflection, распихивание полей из массива и т.д.
AVK>Это мелочи. Там проблемы логического плана. Впрочем, попроси об этом рассказать Синклера, у него хорошо получается.
Да я в общем-то как внутри NHibernate устроен, и так разобрался — в небольшой части, конечно, которая меня интересовала. Потрассировал код, посмотрел. Неплохо самодокументировано — понять, что делается, довольно легко.
Здравствуйте, AndrewVK, Вы писали:
PD>>Не знаю. Спроси VladD2. Он же начал меня в непонимании идей ООП обвинять.
AVK>Он обвинял тебя в неумении ими пользоваться.
О да!
PD>>Я уже на эту тему выступал осенью. Не хочу возвращаться к ней.
AVK>То есть признаешь, что приводить подобное в качестве правильного примера в проектировании программ не стоит?
Нет. Признаю, что повторять два раза одно и то же тем, кто не хочет слышать , дает тот же результат, что и одни раз — не слышат.
PD>>На разных уровнях. Я об этом писал в письме к Владу — переключение между уровнями.
AVK>Чудес не бывает. Человек штука однозадачная.
Бывают и такие. Владельцы единственно правильного мировоззрения. И точно знающие, как правильно нужно делать.
PD>>[Остальная часть этого замечания skipped в связи с этим возражением.]
AVK>Класс! Это нифига не замечание было, это был вопрос.
Да какой там класс. Просто там была формальная логика. Напоминаю
>Предлагая одновременно с абстракциями думать о реализации, ты увеличиваешь количество сущностей на одном уровне.
Так как с этой посылкой я не согласился, то и остально опустил, поскольку решил, что имеет место обычное "если b то", а поскольку b для меня false, то остальная часть оператора не исследуется. Может, зря. Отвечаю.
AVK>Повторю еще раз в краткой форме — как ты предлагаешь бороться с увеличением количества сущностей ввиду того что нужно учитывать аспекты реализации? Или ты считаешь что проектирование с учетом реализации и без такового на одной и той же задаче равноценно по сложности?
Хороший вопрос. Нет, не равноценно. Да, количество сущностей увеличится. Но на разных уровнях.
Рассуждая на уровне верхнем (в действительности их может быть несколько), можно попытаться построить модель, не слишком вдаваясь в детали реализации. На этом уровне надо оценить саму задачу и найти методы ее решения. Идею, так сказать уловить. И допустимые кирпичи.
Но встраивая в систему эти кирпичи, надо тут же вспоминать о свойствах этих кирпичей. Проще говоря, спроектировав пока что воздушный замок из абстрактных блоков, тут же, немедленно переходить к анализу, годятся ли эти блоки для реального замка, который будем строить. Если не годятся — надо тут же, еще пока замок воздушный, приступить к его перепроектированию. Может быть, небольшому, заменить один кирпич на другой, иного сорта,и все дела. А может, такому, что придется весь воздушный замок разрушить и начать стротить его в уме заново. Потому как замечательный он получился, но вот беда — в реальнйо постройке фундамент такое не выдержит. И т.д.
Для архитектора это банальное правило, и тех, кто им не следует, надо не допускать к профессии. Хотя, отмечу, проектирование 30- этажного небоскреба — задача не более простая, чем написание серьезной программы. В машиностроении то же самое — никто не будет начинать делать изделие в металле, не убедившись, что не нарушаются законы сопромата. И т.д.
Только вот некоторые программисты почему-то решили, что можно строить программы, не вдаваясь в свойства материала, из которого строят. Есть кирпичи. Годятся они по размерам ? Да ? Красиво будет ? Да. Все , ясно, кладем здесь эти кирпичи. Прада, потом может выясниться, что они не держат, ну тогда их и заменим.
Вот здесь самое любопытное ИМХО. Пластичность материала дурную шутку сыграла. Кирпичи в настоящем здании -то не заменишь, а рухнет здание — под суд пойдешь. А программистов под суд, слава богу, не отдают, да и кирпичи заменить можно, потратив на это усилия. А можно и не заменять, ведь не рухнет же (в прямом смысле слова), просто качество будет на порядок ниже, так и это не беда , в конце концов убедим себя, что лучше и быть-то не может, да и не надо лучше.
Да, качественный подход потребует более сложного проектирования. Да, при этом число сущностей увеличится (хотя, опять-таки повторяю, на разных уровнях). Может, придется больше работников привлечь. Или специалиста получше а качестве лидера взять. Да, это денег стоит. Да, возможно, их нет, а поэтому придется попроще делать, и качество будет ниже. Все это я понимаю. И не осуждаю, что делать, жизнь такая. Может, мне и самому иногда придется наступать на горло собственной песне и делать не лучшим образом, потому что времени нет или по иной причине. Может (хотя вряд ли) я , сделав так, даже буду потом утверждать, что , дескать, ничего, нормально сделано, все хорошо, и когда заказчик будет меня благодарить, скромно приму эту благодарность и не скажу, что в действительности мог бы сделать это на порядок лучше. Все может быть, жизнь сложная штука, иногда приходится идти на компромиссы.
Но вот одно я делать не буду никогда. Никогда я не стану уверять самого себя, что то, что я сделал, не есть халтуура, а есть именно то, к чему и надо стремиться. Никогда я не стану проповедывать этот халтурный подход в качестве идеала.
AVK>Как определить? Где гарантия что, к примеру, твои сики туда и обратно не вступят в конфликт с файловым кешем ОС, и в результате ты получишь более медленное решение вместо ожидаемого более быстрого? Мой опыт доказывает, что зачастую узкие места обнаруживаются там, где их никто предсказать не смог бы. Так что такой способ не годится.
Ну, в той задаче сики тут не при чем — там об оптимизации вывода по скорости и речи не было. Но вообще — ты прав, конечно.Нет гарантии. Могу ошибиться. Вполне могу. Но ты две вещи смешиваешь.Узкие места обнаруживаются там, где их никто предсказать не смог бы — абсолютно согласен. Но из этого не следует, что надо создавать узкие места там, где вполне очевидно, что они возникнут, если не учитвать свойства (реализацию) материала.
Я в предыдущем письме привел пример с массивом и деревом. Ты на него отвечать не стал. Твое право. Но он как раз и характеризует то, о чем я говорю. Предельно ясно и четко. Может, все же ответишь ? Не возражаю, если в рассмотрение еще и хеш-таблицу введешь.
PD>> Или когда мы попадаем на уровень, который нам неподвластен. PD>> Как только один из этих уровней достигнут — стоп. Дальше думать не о чем — думай не думай, а ничего не изменится.
AVK>Ну и что что неподвластен? Вот кеш у процессора нам тоже неподвластен, однако мы же можем его учитывать?
Я, может, не очень точно выразился. Под словами "неподвластен" я имел в виду, что его поведение не может быть никак учтено, т.е мы не может ничего изменить в программе в зависимости от его поведения. Кэш — можно, поэтому его может быть, и надо учитывать. Хороший пример, кстати. Вот представь, что ты делаешь систему предельно быстрого доступа к данным огромного файла. Можно ли при этом рассуждать только на уровне абстракции "файл" и не принимать во внимание реализацию и кеша, и особенностей ФС ?
Контроллер дисковода — нет, если мы не состоянии как-либо учитывать его поведение. А если в состоянии и это надо — то и его, да. Для драйвера этого контроллера — придется мыслить не только абстракциями "пакет, отсылаемый на устройство", но и думать тут же, наилучшим ли образом этот пакет будет контроллеру передаваться/получаться (если это возможно).
AVK>Итого: на оба заданных вопроса я ответа не получил.
Надеюсь, теперь получил ?
>Исходя из этого задам другие вопросы — насколько сложнее проектирование при постоянном учете реализаций? Во сколько ты оцениваешь стоимость ошибок, вызванных неправильной оценкой эффективности реализации на реальных источниках данных? Насколько оправдано сужение универсальности алгоритма в угоду его производительности? Всегда ли стоит предпочесть более эффективное решение более универсальному? Где золотая середина между скоростью разработки и эффективностью полученного решения? Насколько сильно отразится твой подход на восможности реиспользования и модификации полученного решения?
В общем. я на это уже ответил выше в этом письме. Не на все эти вопросы в деталях, но по сути ответил.
>>>Почему я, при создании сериализации, должен думать о файле, но не должен думать о кластерной структуре ФС?
PD>>Потому что ты не выбираешь ФС.
AVK>Но я выбираю алгоритмы работы с ней. Например на FAT поиск файла это очень дорого, а на NTFS есть индексы и поиск значительно дешевле. Какое грамотное решение ты видишь в подобной ситуации? Наплевать на то, что в случае NTFS мы получаем оверхед и городить свои индексы? Или сделать решение, тормозящее на FAT?
Не знаю. От задачи зависит и от требований. Если это критично и можно потребовать, чтобы FAT не было — это одно. Если придется с FAT мириться — не исключаю даже хранения каталога в ОП в виде своего Б-дерева и отслеживания изменений по ReadDirectoryChanges или на уровне драйвера-фильтра. А может, махнуть рукой — если это не существенно и не критично.
Еще раз — я не обсуждаю решения, пока не ясна задача. Я не верю в универсальные решения. Универсальные решения приводят к неэффективным программам. Я предпочитаю конкретику. Давайте задачу — будем обсуждать.
AVK>Я бы не был столь уверен. Современные винты имеют очень непростое firmware, а каждый процент производительности дисковой подсистемы сегодня очень ценен. Как считаешь — стоит учитывать особенности firmware, или сделать универсальное решение, неоптимальное в каждом конкретном случае? Из той же серии — стоит учитывать кеш процессора, если размер и алгоритмы работы на сегодня довольно существенно разнятся для разных процессоров?
Еще раз — зависит от задачи.
AVK>А как определить что задача такова? И в какой момент это можно сделать? Я лично знаю только один такой способ — произвести замеры на реальном решении или хотя бы прототипе. Но для этого надо архитектуру уже разработать! Замкнутый круг?
Ты ведь , по сути, знаешь, что здесь утверждаешь ? Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает. Так получается ?
Если да — ну тогда я просто не знаю, что сказать. Конечно, не всегда можно теоретически рассчитать то, что мы собираемся создать — в любой области. Иногда можно (строительство, машиностроение), иногда сложнее (ядерная физика, химия, поиск веществ с заранее заданными свойствами). Но чтобы уж так прямо утвержать — "только один способ существует, создать да посмотреть, что получилось" — ИМХО ни в одной области человеческой деятельности в Новое время никто такое не декларировал. Все же есть какая-то наука, а не только эмпирика.
Вот тебе тот же пример с деревом/массивом. Я может, в другом месте ошибусь — может. Может там оно медленно работать будет — может. Но означает ли это , что так уж ни о чем и думать не надо, когда массив здесь вставляешь ? Годится он сюда по своим методам/свойствам — годится. Берем. Неужели если я подумаю о том, что вставка в него очень дорогая по времени, а у меня вставок очень много, а время критично — и не откажусь от него еще на этапе абстракций, не написав ни одной еще строчки — неужели это правильно будет ? Я не верю, что ты сам так сделаешь. Или сделаешь все же ?
AVK>Ну вот тогда и не делай из них выводы. Единственное использование аналогий в споре, не являющееся демагогией, это применение их в качестве иллистраций каких то высказываний. Ты же сделал вывод, опираясь только на аналогию (здание рухнет, если не рассчитать прочность каждого кирпича -> программа рухнет, если не рассчитать прочность каждого кусочка кода).
Цитату , пожалуйста! Точную. Где я говорил, что программа рухнет.
PD>> Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
Вот это я говорил. Передергивать не надо. Некрасиво.
PD>>Да я в общем-то как внутри NHibernate устроен, и так разобрался — в небольшой части, конечно, которая меня интересовала. Потрассировал код, посмотрел. Неплохо самодокументировано — понять, что делается, довольно легко.
AVK>А как насчет эффективности?
Да как... Так себе. Насчет эффективности в плане работы с БД — вроде довел до того состояния, когда лишние данные не запрашиваются и все SELECT и т.д. под контролем. А что касается того, что они там данные из строки БД читают в массив, а потом долго и упорно исследуют мой класс на предмет того, что куда и как из массива загнать — плевался, конечно. Но не властен я был в этой работе от NHibernate отказаться.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Я уже на эту тему выступал осенью. Не хочу возвращаться к ней.
AVK>>То есть признаешь, что приводить подобное в качестве правильного примера в проектировании программ не стоит?
PD>Нет. Признаю, что повторять два раза одно и то же тем, кто не хочет слышать , дает тот же результат, что и одни раз — не слышат.
А ты сам слышишь?
PD>>>На разных уровнях. Я об этом писал в письме к Владу — переключение между уровнями.
AVK>>Чудес не бывает. Человек штука однозадачная.
PD>Бывают и такие. Владельцы единственно правильного мировоззрения. И точно знающие, как правильно нужно делать.
Это ты к чему? Можно попроще свою мысль выразить?
AVK>>Повторю еще раз в краткой форме — как ты предлагаешь бороться с увеличением количества сущностей ввиду того что нужно учитывать аспекты реализации? Или ты считаешь что проектирование с учетом реализации и без такового на одной и той же задаче равноценно по сложности?
PD>Хороший вопрос. Нет, не равноценно. Да, количество сущностей увеличится. Но на разных уровнях.
Так, давай попроще. Имеем некую модель (пота только абсракцию), которая состоит из N уровней. Очевидно что количество различных абстракций на каждом уровне не должно быть большим, иначе человек не сможет с такой архитектурой работать. Путь у нас заселенность уровней близка к оптимуму. Теперь мы начинаем в модели учитывать реализацию — автоматически заселенность уровней увеличится (каких — неважно). Единственный выход привести модель в человекопонимаемое состояние — увеличить количество уровней, так?
PD>Рассуждая на уровне верхнем (в действительности их может быть несколько), можно попытаться построить модель, не слишком вдаваясь в детали реализации.
Ага, ты сам пришел к правильным выводам. Модель надо начинать строить не заморачиваясь особенно конкретикой реализации.
PD>Но встраивая в систему эти кирпичи, надо тут же вспоминать о свойствах этих кирпичей.
Под встраиванием в систему кирпичей ты понимаешь уже создание реализаций?
PD> Проще говоря, спроектировав пока что воздушный замок из абстрактных блоков, тут же, немедленно переходить к анализу, годятся ли эти блоки для реального замка, который будем строить.
Подожди. Очевидно, что реализация тоже будет распределена послойно. Так как правильно — создать верхний слой, затем его реализацию, затем слои пониже, затем их реализацию и так до самого дна, или сразу спроектировать все слои, а потом только заниматься реализацией?
PD> Если не годятся — надо тут же, еще пока замок воздушный, приступить к его перепроектированию.
То есть замок у тебя весь готов на момент реализации?
PD> Может быть, небольшому, заменить один кирпич на другой, иного сорта,и все дела. А может, такому, что придется весь воздушный замок разрушить и начать стротить его в уме заново. Потому как замечательный он получился, но вот беда — в реальнйо постройке фундамент такое не выдержит. И т.д.
Ну вобщем это и называется рефакторинг.
PD>Только вот некоторые программисты почему-то решили, что можно строить программы, не вдаваясь в свойства материала, из которого строят.
Ты, мне кажется, неверно понял собеседников. Никто не предлагает вобще заморачиваться реализацией. Идея другая — мы создаем грубую модель, на основе которой грубо работающий прототип (с простейшей реализацией). Потом смотрим на него и получаем новую информацию — чего не учли, где ошиблись. И начинаем проблемные места перепроектировать и создавать уже боевую реализацию. Потом получаем второй прототип и процесс повторяем. По факту в нашем проекте обычно выстраивается цепочка из 4-5 прототипов, прежде чем начинает писаться код, который останется в релизе.
PD>Вот здесь самое любопытное ИМХО. Пластичность материала дурную шутку сыграла. Кирпичи в настоящем здании -то не заменишь, а рухнет здание — под суд пойдешь. А программистов под суд, слава богу, не отдают, да и кирпичи заменить можно, потратив на это усилия.
И что в этом дурного?
PD> А можно и не заменять, ведь не рухнет же (в прямом смысле слова), просто качество будет на порядок ниже, так и это не беда , в конце концов убедим себя, что лучше и быть-то не может, да и не надо лучше.
Тут уж не подход виноват, это банальная халтура. И она везде плоха, вне зависимости от подхода.
PD>Да, качественный подход потребует более сложного проектирования. Да, при этом число сущностей увеличится (хотя, опять-таки повторяю, на разных уровнях). Может, придется больше работников привлечь. Или специалиста получше а качестве лидера взять. Да, это денег стоит.
Повышение качества при любом подходе стоит денег.
PD>Но вот одно я делать не буду никогда. Никогда я не стану уверять самого себя, что то, что я сделал, не есть халтуура, а есть именно то, к чему и надо стремиться. Никогда я не стану проповедывать этот халтурный подход в качестве идеала.
А что, кто то проповедует халтуру?
PD>Ну, в той задаче сики тут не при чем — там об оптимизации вывода по скорости и речи не было. Но вообще — ты прав, конечно.Нет гарантии. Могу ошибиться. Вполне могу.
Давай примем это за аксиому, ок?
PD> Но ты две вещи смешиваешь.Узкие места обнаруживаются там, где их никто предсказать не смог бы — абсолютно согласен. Но из этого не следует, что надо создавать узкие места там, где вполне очевидно, что они возникнут, если не учитвать свойства (реализацию) материала.
Верно. Но вот какая неприятная зависимость — чем сложнее система, тем труднее предположить где будут узкие места. Отсюда другая зависимость — чем крупнее проект, тем чаще его придется перелывать. Наконец отсюда вывод — чем крупнее проект, тем меньше конкретики нужно в него запихивать на каждом этапе (особенно на начальных этапах, где вероятность ошибки близка к 100%).
Вот поэтому и предлагается не заморачиваться хорошими реализациями в первых прототипах, поскольку велика вероятность, что из-за ошибок проектирования хорошую реализацию в лучшем случае придется сильно переделать, а в худшем она в полном объеме пойдет в корзину. И чем больше и сложнее проект, тем больше эта вероятность.
Это я все не из пальца высосал, это все я постоянно наблюдаю в реальной разработке. Опять же в текущем проекте наиболее качественные куски, которые долго живут без сильных переделок, были переписаны по 3-4 раза. Кода, который был один раз написан в самом начале практически не осталось.
PD>Я в предыдущем письме привел пример с массивом и деревом. Ты на него отвечать не стал. Твое право. Но он как раз и характеризует то, о чем я говорю. Предельно ясно и четко. Может, все же ответишь ? Не возражаю, если в рассмотрение еще и хеш-таблицу введешь.
Все это сильно зависит от платформы. Например в .NET массив это более низкоуровневая абстракция, нежели дерево или словарь. Только я не могу понять — какое это имеет отношение к проектированию?
AVK>>Ну и что что неподвластен? Вот кеш у процессора нам тоже неподвластен, однако мы же можем его учитывать?
PD>Я, может, не очень точно выразился. Под словами "неподвластен" я имел в виду, что его поведение не может быть никак учтено,
Почему нет?
PD> т.е мы не может ничего изменить в программе в зависимости от его поведения.
Могу. Надеюсь доказывать не надо?
PD> Кэш — можно, поэтому его может быть, и надо учитывать. Хороший пример, кстати. Вот представь, что ты делаешь систему предельно быстрого доступа к данным огромного файла. Можно ли при этом рассуждать только на уровне абстракции "файл" и не принимать во внимание реализацию и кеша, и особенностей ФС ?
На первом этапе можно.
AVK>>Итого: на оба заданных вопроса я ответа не получил.
PD>Надеюсь, теперь получил ?
Не на все.
AVK>>Но я выбираю алгоритмы работы с ней. Например на FAT поиск файла это очень дорого, а на NTFS есть индексы и поиск значительно дешевле. Какое грамотное решение ты видишь в подобной ситуации? Наплевать на то, что в случае NTFS мы получаем оверхед и городить свои индексы? Или сделать решение, тормозящее на FAT?
PD>Не знаю.
А кто знает?
PD> От задачи зависит и от требований.
Ну задачу можно придумать. Пусть это будет кеш прокси-сервера.
PD> Если это критично и можно потребовать, чтобы FAT не было — это одно.
Помнится ты в свое время утверждал что эффективность в любом случае критична. Впрочем ладно. На этот вопрос я ответить не могу — может критично, а может и нет, пока не не попробуешь, не узнаешь.
PD>Еще раз — я не обсуждаю решения, пока не ясна задача.
А она не может быть ясна на 100% в начале разработки, это мы чуть выше вроде как уяснили.
PD> Я не верю в универсальные решения. Универсальные решения приводят к неэффективным программам. Я предпочитаю конкретику. Давайте задачу — будем обсуждать.
Ну задачу я тебе дал.
PD>Ты ведь , по сути, знаешь, что здесь утверждаешь ? Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает. Так получается ?
Ага.
PD>Если да — ну тогда я просто не знаю, что сказать.
А хотелось бы услышать твое мнение. Что ты будешь в этой ситуации делать? Понадеешься на интуицию?
PD>Но чтобы уж так прямо утвержать — "только один способ существует, создать да посмотреть, что получилось" — ИМХО ни в одной области человеческой деятельности в Новое время никто такое не декларировал. Все же есть какая-то наука, а не только эмпирика.
Очень мало аналитической науки в программировании, исчезающе мало. Аналитическое моделирование СМО затыкается на сверхпримитивных системах. Академического курса теории СМО мне хватило, чтобы понять, что даже процессор с парой-тройкой уровней кеша аналитически практически не описывается. Что же говорить о реальных системах, чье поведение неизмеримо сложнее?
PD> Я может, в другом месте ошибусь — может. Может там оно медленно работать будет — может. Но означает ли это , что так уж ни о чем и думать не надо, когда массив здесь вставляешь ? Годится он сюда по своим методам/свойствам — годится. Берем. Неужели если я подумаю о том, что вставка в него очень дорогая по времени
Она не дорогая, она просто невозможна.
PD>, а у меня вставок очень много, а время критично — и не откажусь от него еще на этапе абстракций, не написав ни одной еще строчки — неужели это правильно будет ? Я не верю, что ты сам так сделаешь. Или сделаешь все же ?
Я делаю очень просто — выбираю минимальную абстракцию (например IList<T> или ICollection<T> или даже IEnumerable<T>). И мне совершенно пофигу сколько стоит вставка — массив в любом случае не должен меняться снаружи напрямую, поскольку отследить внутри это невозможно. Ну а внутри я всегда волен менять массив на что угодно другое, как только он станет неподходящим. Единственное для чего можно использовать в публичном интерфейсе массив напрямую — как контейнер для параметров или возвращаемого значения.
AVK>>Ну вот тогда и не делай из них выводы. Единственное использование аналогий в споре, не являющееся демагогией, это применение их в качестве иллистраций каких то высказываний. Ты же сделал вывод, опираясь только на аналогию (здание рухнет, если не рассчитать прочность каждого кирпича -> программа рухнет, если не рассчитать прочность каждого кусочка кода).
PD>Цитату , пожалуйста! Точную. Где я говорил, что программа рухнет.
Хорошо, Влад, а объясни, в чем я неправ. Я ведь не против того, что нужны эти абстракции. Но почему я не прав, когда все же при этом думаю о свойствах кирпича, из которого эти колонны строить буду. Ведь не воздушный замок же я строю! Почему я должен от свойств материала отрешаться ? Ведь рухнуть же может здание, не выдержат они и будет ЧП. А абстрактно — колонны вещь замечательная. Красиво и приятно. А потом выяснится вдруг — крышу не держат. Примеры напомнить ?
Что ты этим хотел сказать?
PD>>> Дом развалится, это верно. Программа не развалится, просто работать будет в несколько раз медленнее и памяти кушать больше. Что мы и наблюдаем.
PD>Вот это я говорил. Передергивать не надо. Некрасиво.
Все запротоколированно. Можешь открыть свое сообщение и посмотреть.
Здравствуйте, AndrewVK, Вы писали:
AVK>А ты сам слышишь?
Стараюсь .
PD>>Бывают и такие. Владельцы единственно правильного мировоззрения. И точно знающие, как правильно нужно делать.
AVK>Это ты к чему? Можно попроще свою мысль выразить?
Можно, конечно, если это слишком сложно. Люди, которые уверовали в истину в последней инстанции, и уверенно ее продвигают, не считаясь ни с чем.
Или это опять слишком сложно ?
AVK>Так, давай попроще. Имеем некую модель (пота только абсракцию), которая состоит из N уровней. Очевидно что количество различных абстракций на каждом уровне не должно быть большим, иначе человек не сможет с такой архитектурой работать. Путь у нас заселенность уровней близка к оптимуму. Теперь мы начинаем в модели учитывать реализацию — автоматически заселенность уровней увеличится (каких — неважно). Единственный выход привести модель в человекопонимаемое состояние — увеличить количество уровней, так?
Нет. См. ниже.
PD>>Рассуждая на уровне верхнем (в действительности их может быть несколько), можно попытаться построить модель, не слишком вдаваясь в детали реализации.
AVK>Ага, ты сам пришел к правильным выводам. Модель надо начинать строить не заморачиваясь особенно конкретикой реализации.
А ты процитируй до конца.
PD>... Проще говоря, спроектировав пока что воздушный замок из абстрактных блоков, тут же, немедленно переходить к анализу, годятся ли эти блоки для реального замка, который будем строить.
PD>>Но встраивая в систему эти кирпичи, надо тут же вспоминать о свойствах этих кирпичей.
AVK>Под встраиванием в систему кирпичей ты понимаешь уже создание реализаций?
Продумывание. Решение, будет ли она примемлемой. Дом еще не строится. Но думать, выдержат ли кирпичи, стоит уже.
PD>> Проще говоря, спроектировав пока что воздушный замок из абстрактных блоков, тут же, немедленно переходить к анализу, годятся ли эти блоки для реального замка, который будем строить.
AVK>Подожди. Очевидно, что реализация тоже будет распределена послойно. Так как правильно — создать верхний слой, затем его реализацию, затем слои пониже, затем их реализацию и так до самого дна, или сразу спроектировать все слои, а потом только заниматься реализацией?
А не мог бы ты пояснить, что означает создать верхний слой и его реализацию без создания слоев пониже ? Псевдокод написать, что ли ?
PD>> Если не годятся — надо тут же, еще пока замок воздушный, приступить к его перепроектированию.
AVK>То есть замок у тебя весь готов на момент реализации?
Воздушный — готов. Реализация его при этом уже продумана. Код еще не писался.
PD>> Может быть, небольшому, заменить один кирпич на другой, иного сорта,и все дела. А может, такому, что придется весь воздушный замок разрушить и начать стротить его в уме заново. Потому как замечательный он получился, но вот беда — в реальнйо постройке фундамент такое не выдержит. И т.д.
AVK>Ну вобщем это и называется рефакторинг.
Пострефакторинг я бы сказал.
PD>>Только вот некоторые программисты почему-то решили, что можно строить программы, не вдаваясь в свойства материала, из которого строят.
AVK>Ты, мне кажется, неверно понял собеседников. Никто не предлагает вобще заморачиваться реализацией. Идея другая — мы создаем грубую модель, на основе которой грубо работающий прототип (с простейшей реализацией). Потом смотрим на него и получаем новую информацию — чего не учли, где ошиблись. И начинаем проблемные места перепроектировать и создавать уже боевую реализацию. Потом получаем второй прототип и процесс повторяем. По факту в нашем проекте обычно выстраивается цепочка из 4-5 прототипов, прежде чем начинает писаться код, который останется в релизе.
Повторяю — речь идет о том, чтобы на этапе проектирования учитыват свойства материала. Ничего больше я не говорил, и не собирался.
PD>>Вот здесь самое любопытное ИМХО. Пластичность материала дурную шутку сыграла. Кирпичи в настоящем здании -то не заменишь, а рухнет здание — под суд пойдешь. А программистов под суд, слава богу, не отдают, да и кирпичи заменить можно, потратив на это усилия.
AVK>И что в этом дурного?
Да ничего.
AVK>Повышение качества при любом подходе стоит денег.
Не спорю.
PD>>Но вот одно я делать не буду никогда. Никогда я не стану уверять самого себя, что то, что я сделал, не есть халтуура, а есть именно то, к чему и надо стремиться. Никогда я не стану проповедывать этот халтурный подход в качестве идеала.
AVK>А что, кто то проповедует халтуру?
Увы, да.
PD>>Ну, в той задаче сики тут не при чем — там об оптимизации вывода по скорости и речи не было. Но вообще — ты прав, конечно.Нет гарантии. Могу ошибиться. Вполне могу.
AVK>Давай примем это за аксиому, ок?
OK.
PD>> Но ты две вещи смешиваешь.Узкие места обнаруживаются там, где их никто предсказать не смог бы — абсолютно согласен. Но из этого не следует, что надо создавать узкие места там, где вполне очевидно, что они возникнут, если не учитвать свойства (реализацию) материала.
PD>>Я в предыдущем письме привел пример с массивом и деревом. Ты на него отвечать не стал. Твое право. Но он как раз и характеризует то, о чем я говорю. Предельно ясно и четко. Может, все же ответишь ? Не возражаю, если в рассмотрение еще и хеш-таблицу введешь.
AVK>Все это сильно зависит от платформы. Например в .NET массив это более низкоуровневая абстракция, нежели дерево или словарь. Только я не могу понять — какое это имеет отношение к проектированию?
Сейчас поясню.
Платформа та или другая — массив есть структура данных. В смысле, допустим, известной книги Вирта. Просто структура данных — набор последовательно расположенных элементов одинакового типа. Хочешь — оставь ее голой, как в С или Фортране. Хочешь — окружи классом, как в С++ или C#. Неважно. Выскокоуровневая или нет — мне не важно. Это просто структура данных.
И как стуктура данных, она определяет свое поведение в смысле зависимости времени операции от размера. O(?), проще говоря. Поиск в линейном неупорядоченном массиве — O(N), в упорядоченном — O(log(N)). Доступ по индексу — O(1). Вставка в произвольное место — O(N). И т.д.
Это, так сказать, свойства кирпича.
Массив, действительно, является самой низкоуровнвой структурой, потому что память тоже линейна (она тоже массив). Другие структуры (список, стек, дерево) непосредственно на память не укладываются и должны быть реализованы на базе чего-то. Список на основе массива. Список на основе связанных ссылок. Дерево на основе массива или на основе связанных ссылок И т.д. Все это изучается в курсе "Структуры данных", там же рассматриваются различные реализации и их временные характеристики.Например, список на основе массива с непрерывным хранениме потребует O(N) для вставки, а с ссылочным — O(1) для вставки, но если нужен поиск, то опять O(N). И т.д.
Так вот, вопрос простой. Есть необходимость хранить некие данные. Для того, чтобы программа работала эффективно, надо учесть свойства материала. Применяя ту или иную структуру данных (абстракцию), надо это учесть. Дерево, к примеру, позволит мне иметь O(log(N) для вставки, удаления и поиска. Линейный список — не позволит. Массив тоже. Хеш-таблица — о ней особо.
А учитывать это надо в зависимости от задачи. Данных немного, поиск часто, вставки редкие — годится массив, к примеру. Вставки частые, данных много — не годится массив, хотя он чудо как хорошо в абстрактные постройки укладывается. Там как раз к элементам по смыслу задачи надо по индексу обращаться. Пронумерованы они самим характером задачи.
А я все же предлагаю подумать, не приведет ли это к тому, что доступ к данным будет просто и логичен, а скорость — никуда не годна. И подумаю. И выкину массив, поняв, что он не годится (из-за того, что нет у него нужной мне реализации). И введу туда дерево. И потеряю доступ по индексу, который мне чудо как нравится. И придется мне по ключу поиск элемента вести в дереве поиска. Неудобно это и не укладывается в абстракцию. Зато я знаю, что не будет у меня O(N), а будет O(Log(N)).
Впрочем нет, не будет. Дерево-то дерево, а не выйдет ли оно вырожденным ? Так ведь я могу зря все сделать. Опять к задаче обращаться придется. Как там ключи в дерево добавляются/удаляются ? Есть риск плохой балансировки ? Если нет — ну что же, в среднем случае я всего в 1.3 раза рискую проиграть. Может, тм пренебречь можно. А может, мне и в 1.1 раза нельзя — т задачи зависит. А если есть такой риск — будем АВЛ дерево строить.
И т.д. И т.п.
Думаю, все тебе это известно.
А теперь вопрос.
Предположим, у тебя именно такая ситуация возникла. Что будешь делать ?
1. Вставишь массив, доведешь код до рабочего состояния, убуедишься в том. что нужные характеристики не получаются
или
2. Все же проведешь тот анализ, о котором я написал и решишь, что лучше
Вот тебе конкретная ситуация. Выбирай.
Сорри, но время 20:24. Пора домой идти. На остальную часть отвечу в понедельник, если время будет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Можно, конечно, если это слишком сложно. Люди, которые уверовали в истину в последней инстанции, и уверенно ее продвигают, не считаясь ни с чем.
PD>Или это опять слишком сложно ?
Сложно, поскольку я до сих пор не вник — какая связь между твоим высказыванием и неспособностью обычного человека думать сразу о нескольких вещах в один момент времени.
AVK>>Под встраиванием в систему кирпичей ты понимаешь уже создание реализаций?
PD>Продумывание. Решение, будет ли она примемлемой. Дом еще не строится. Но думать, выдержат ли кирпичи, стоит уже.
А как ты это делаешь? Пусть у тебя 10000 кирпичей. Запомнить их все нереально. Ты их на бумажке записываешь? Или как то еще?
AVK>>Подожди. Очевидно, что реализация тоже будет распределена послойно. Так как правильно — создать верхний слой, затем его реализацию, затем слои пониже, затем их реализацию и так до самого дна, или сразу спроектировать все слои, а потом только заниматься реализацией?
PD>А не мог бы ты пояснить, что означает создать верхний слой и его реализацию без создания слоев пониже ? Псевдокод написать, что ли ?
А что тут сложного? Реализуешь самый верхний слой, а в детализации вставляешь либо константный вывод без вычисления, либо выкидывание исключения о том, что метод не реализован.
AVK>>То есть замок у тебя весь готов на момент реализации?
PD>Воздушный — готов. Реализация его при этом уже продумана.
А как оно зафиксировано? Только в памяти?
PD> Код еще не писался.
Но уже весь продуман?
AVK>>Ну вобщем это и называется рефакторинг.
PD>Пострефакторинг я бы сказал.
Нет никакого пререфакторинга и пострефакторинга. Рефакторинг может проводится в любой момент.
PD>Повторяю — речь идет о том, чтобы на этапе проектирования учитыват свойства материала.
А я тебя спросил — до какой степени и как справится с резким усложнением дизайна за счет увеличения объема информации, которую надо учитывать.
AVK>>Повышение качества при любом подходе стоит денег.
PD>Не спорю.
А о чем ты тогда споришь?
AVK>>А что, кто то проповедует халтуру?
PD>Увы, да.
Можно показать пальцем?
PD>Так вот, вопрос простой. Есть необходимость хранить некие данные. Для того, чтобы программа работала эффективно, надо учесть свойства материала. Применяя ту или иную структуру данных (абстракцию), надо это учесть.
Почему? До сих пор ты говорил не об абстракциях, а о реализациях. И список на массивах, и массив, и связанный список это IList. Вот IList — абстракция. А вот кто сколько и что делает — характеристики реализации. Хеш же и дерево — это вобще другие структуры, как их можно сравнивать со списком мне неясно.
PD>А я все же предлагаю подумать, не приведет ли это к тому, что доступ к данным будет просто и логичен, а скорость — никуда не годна. И подумаю.
На этапе проектирования? Зачем? Почему просто не указать IList? Ну или свой интерфейс, в котором будут указаны нужные операции. Или ты хочешь конкретные реализации списков выставлять в публичный интерфейс?
PD>Предположим, у тебя именно такая ситуация возникла. Что будешь делать ?
PD>1. Вставишь массив, доведешь код до рабочего состояния, убуедишься в том. что нужные характеристики не получаются PD>или PD>2. Все же проведешь тот анализ, о котором я написал и решишь, что лучше
PD>Вот тебе конкретная ситуация. Выбирай.
Спроектирую не конкретизируя какую реализацию буду использовать вплоть до того, как начну писать код. В публичном интерфейсе укажу IList или собственный интерфейс.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не пойдет. "форма с которой легко манипулировать" — слишком неконкретно.
От это она и есть — абстракция.
PD> Для меня массив — форма с которой достаточно легко манипулировать. Поэтому выкладывание графа в массив есть перевод его именно в такую форму. Но это не сериализация.
Почему же? Очень даже сериализация. Просто массив несколько менее общая абстракция. Хотя и его можно воспримать как просто последоватльную форму... набор байтов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Предлагаю следсвтенный эксперемент. Делашь тест сохраняющий данные в файл твоим способом и с использованием промежуточного MemoryStream. Затем сравниваем результаты и делаем выводы.
PD>А что сравнивать-то будем ?
Скорость. А ты что подумал?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
PD>> Для меня массив — форма с которой достаточно легко манипулировать. Поэтому выкладывание графа в массив есть перевод его именно в такую форму. Но это не сериализация.
VD>Почему же? Очень даже сериализация.
Я имел в виду реализацию графа на базе массива (матрицу смежности)
>Просто массив несколько менее общая абстракция. Хотя и его можно воспримать как просто последоватльную форму... набор байтов.
Ну так можно все под сериализацию подвести. Все у нас в конце концов набор байтов.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>>Предлагаю следсвтенный эксперемент. Делашь тест сохраняющий данные в файл твоим способом и с использованием промежуточного MemoryStream. Затем сравниваем результаты и делаем выводы.
PD>>А что сравнивать-то будем ?
VD>Скорость. А ты что подумал?
Нет, в условиях, когда используется доп. память, я принципиально скорости не сравниваю. Даже если при этом лишние действия делаются. Только при равных условиях по памяти.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ничего себе заявление!. Я говорю — От задачи зависит и от требований. Мне в ответ — ну вот тебе задача.
Что тебе не нравится? Вполне реальная задача.
PD> Без указания требований к железу,
Среднестатистический писюк на сегодня.
PD> без указания требованйи к софту
Какие требования к софту тебе нужны?
PD>, без подробной спецификации
Подробную спецификацию это кодерам выдают и то не всегда. А ты, коль уж архитектор, работаешь не в тепличных, а вреальных условиях. Ты сам эту спецификацию создать должен.
PD> — на тебе задачу, иди и скажи, как решать будешь. У Вас что, принятно так техзадания выдавать?
Это не у нас, это везде. Кто тебе эту спецификацию писать будет? Есть рынок, есть реальное железо — welcome to real world.
PD> Сделайте мне прокси-сервер — и радостный девелопер отправляется его делать, не поинтересовавшись даже, для каких целей он нужен,
Для целей кеширования трафика интернета рядового пользователя.
PD>Вот когда подробные спецификации будут — тогда и поговорим.
Мда, плохой из тебя архитектор выходит.
PD>Узнаешь. Вполне узнаешь. Мне по крайней мере это удавалось.
Судя по тем преджположениям, что ты делал в форуме позволю себе не поверить.
AVK>>А она не может быть ясна на 100% в начале разработки, это мы чуть выше вроде как уяснили.
PD>На 100% — не может. Но это не означает, что нельзя оценить то, что можно.
Помнишь я тебе вопросы задавал? Ты на большую часть не ответил. Попробуй, соотносясь с этим утверждением вопросы прочитать еще раз.
PD>Кстати, вот тебе вопрос как раз по твоему примеру, прокси. Ты мне тут много и упорно доказывал, что думать о реализации означает плодить сущности, а мозг человека не в состоянии охватить слишком многое. Вполне разумная мысль, не могу не согласиться. Только вот вопрос — а почему мозг одного человека ?
Потому что до сих пор не существует технологий, позволяющих проектировать систему на верхних уровнях, учитывая только часть архитектурыю
PD> И если все же одного — почему нельзя это по времени растянуть.
Потому что рынок.
PD>Как ты будешь прокси-сервер делать, и что там еще будет — опустим. Но вот есть подзадача — хранить получаемые файлы на диске, стирать их там периодически и т.д. Естественно, я полагаю, что спецификации разработаны, а значит, можно уже сейчас оценить предполагаемое количество файлов общее, в единицу времени, и т.д.
Оцени.
PD>Или другому это поручи. Неплохо будет, если он FAT/NTFS хорошо знает, и вообще на этих делах собачку съел..
Но мне то что делать? Я ведь должен архитектуру дальше делать. Я не могу оставить неспроектированным кусок целиком. Мне нужно ввести абстракцию, изолирующую меня от специфики хранения. Но, пользуясь твоей методикой, я этого сделать не могу, потому что она должна быть согласована с реализацией, а реализацию я не могу никак определить.
PD>Sinclair мне тут как-то популярно объяснял, что такое декомпозиция. Ликбез, так сказать, устроил. Вот я тебе эту декомпозицию и пересылаю. Декомпозируй (в данном случае подзадача выделяется элементарно) и отдай другому.
При декомпозиции обычно учитывают только входные данные и структуру. Как делать декомпозицию с обязательным учетом реализации я не знаю.
AVK>>Ну задачу я тебе дал.
PD>Я тебе тоже могу задачу дать. Напиши текстовый редактор. К завтрашнему дню. Берешься ?
Это называется передергивание.
PD>Но вообще на вопрос — что буду делать — ответ простой. Я просто не согласен с исходной посылкой "Невозможно априорно оценить качество решения, кроме как соорудив его во плоти и крови и посмотрев, как оно работает.". Ты согласен, я — нет. Так что я ничего в этой ситуации делать не должен.
Ну вот теперь самое время вернуться к той зависимости, о которой я писал — чем крупнее и сложнее система, тем сложнее предсказать ее поведение и реальные характеристики. Дальше думай сам.
PD>Системы бывают сильно и слабосвязанные, как тебе известно, конечно. Если система очень сильно связанная, то да, трудно сказать, где что может возникнуть. Но далеко не всегда это так.
Я тебе больше скажу — если система сильно связанная это явный косяк в архитектуре. Вот только чем меньше связность системы, тем выше оверхед на взаимодействие между ее кусками. Оверхед как раз из-за того, что ты тут стараешься представить как неверный подход — слишком куцые абстракции не позволяют сильно оптимизировать под конкретику.
Вот мы и пришли к моменту, который ты упорно пытаешься игнорировать — жесткая привязка абстракций к реализации ведет к сильносвязным системам, что, в свою очередь резко уменьшает предсказуемость такой системы и резко же усложняет ее дальнейшую модификацию. Переход к слабосвязным системам снимает структурные проблемы, но ведет к снижению эфективности на стыках. Найти золотую середину — одна из сверхзадач проектирования архитектуры. Говорить сейчас о конкретном ее значении без конкретики конечно бессмысленно, но одно очевидно — чем больше у нас ресурсов, тем сильнее золотая середина смещается к слабосвязным решениям.
Что же касается того, как эту середину выбрать, то ответ тоже уже был дан. Нужно проектировать максимально слабосвязное решение, а потом, по мере необходимости, мигрировать в узких местах к решениям более связным. Здесь, опять же, замечу, что с увеличением количества ресурсов узкие места совсем не обязательно остануться там же, где и были. Т.е., перефразируя, оптимизации по потреблению ресурсов сильно зависят от конкретного количества и соотношения этих ресурсовю
PD> И твой пример с прокси-сервером — как раз этому подтверждение. В конце концов, прокси — сервер или тестовая программа будет эти файлы генерировать — не все ли равно ? Подсистема почти автономна. И решалась эта задача не один раз — не ты же первый хранилище файлов создаешь при таких-то требованиях ? Так что оценить здесь можно, в крайнем случае тесты сделать — на их создание двух дней за глаза хватит. Продумать все, как следует. А не писать сразу первое, что вголову придет.
А зачем делать тесты, если можно сразу начать проектировать систему? Если, как ты утверждаешь, у тебя очень хорошая интуиция, то и переделывать потом ничего не придется.
PD>Вот, кстати, зачем в kerio они свой файл для прокси-кэша сделали ? Большая же работа — свою ФС (или что-то такое) внутри этого файла городить ? А все же сделали...
А оно там было с первых версий?
PD>И вот теперь приходим к выводу, что надо свою псевдо-ФС на отдельном файле делать. Положение — хуже губернаторского, до дедлайна две недели, все, в общем, готово, но из-за этого узкого звена новый огромный кусок появился, и его за 2 недели никак не сделать (допустим).
Устанавливать жесткие дедлайны до того, как будет получен работающий прототип — признак недалекого ума РМов.
PD>А что, нельзя было об этом за 3 месяца до срока узнать ? Подумать немного, интуицию привлечь да парочку тестов соорудить.
Еще раз — чем тесты лучше прототипа?
AVK>>Она не дорогая, она просто невозможна.
PD>Почему невозможна ?
Потому.
PD> Вполне возможна ? Создаем новый массив длины L+1, копируем в него элементы до нужной позиции, потом этот элемент, потом оставшиеся, исходный массив уничтожаем.
Массив сам такое не умеет. То, что ты написал называется список на массивах. И это тоже не абстракция. Речь же идет о выборе абстракций.
PD>Хм... Ну а если в итоге окажется, что ни одной имплементации IList нет с нужным быстродействием ?
Блин, реализации.
PD> К примеру, выяснится, что лучше всего для хранения HashTable использовать, это все же (условно) O(1) на вставку и на поиск, а там — не получается.
Я тебе уже кажется говорил — хеш-таблица и список это разные вещи, они не взаимозаменяемы.
PD> Или дерево двоичное (допустим, IList не поддерживает). Тогда как , все переделывать ?
Писать свою реализацию IList. А в чем проблема?
PD>Да то, что и в других места, когда говорил, что здание может рухнуть. Таких мест несколько. Про здание я говорил. А не про программу. Ясно же сказал в письме к тебе
Офигеть. Так у нас тут форум по строительству зданий оказывается. А я то думал ... Ну тогда как нибудь без меня, я в кирпичах не специалист, за всю свою жизнь только один дом и построил.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Pavel Dvorkin, Вы писали:
Д>Умение писать работоспособный код — это вопрос минимального профессионального соответствия. Та самая планка, ниже которой стоит слово "уволить немедленно". Настоящего квалифицированного программиста отличает умение писать не только работоспособный, но и легко читаемый, поддерживаемый, расширяемый код. Поэтому не надо рассказывать нам, что твои программы работают. Лучше расскажи, какое количество профессиональных программистов занимается/занималось поддержкой твоего кода.
Ни один. Проект сделан надолго, изменения в него вносить не придется. По причине того, что предметная область не будет изменена в течение ближайших десятилетий, да и вообще в обозримом будущем. Если не будет светопреставления. Никаких расширений там быть не может по определению — за полной их ненадобностью. Поверь, это действительно так.
Да, конечно, ситуация нетипичная, я понимаю. Но на тему поддержки и расширения кода я сейчас высказываться не буду — не готов. Будет время — трону и эту священную корову за вымя . В отдельном топике.
>Неплохо бы также узнать их мнение о твоем коде.
Ну если уж тебя это так интересует... Специально для тебя разыскал в почте.
Pavel,
I'd just like to thank you for all your effort this year. You have made
a major contribution to the success of the project so far. I hope
you will continue to enjoy the challenges of the project in 2003. Although you
are so far away you are always included in our thoughts and
conversations. We all appreciate the effort you have made.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>Вот конкретно это место мне совершенно непонятно. Отказавшись от своей ФС мы очень значительно сократили расходы. Поэтому я не вижу причины, по которой мы встрянем с производительностью за две недели до дедлайна.
А просто по совету AndrewVK начали с прототипа. Не слишком заботясь о реализации. А в итоге там оказалось узкое звено. И его теперь иначе не расшить.
А если ты скажешь, что надо было ПМ'у с самого начала думать — так Андрей же и утверждает, что пока не сделаем — это ясно не будет, не может быть.
>Идея другая — мы создаем грубую модель, на основе которой грубо работающий прототип (с простейшей реализацией). Потом смотрим на него и получаем новую информацию — чего не учли, где ошиблись. И начинаем проблемные места перепроектировать и создавать уже боевую реализацию. Потом получаем второй прототип и процесс повторяем.
Кстати, вспомнил забавную историю на этот счет.
К счастью, вскоре настал день, когда заработала система моделирования
технических характеристик OS/360. Первые результаты показали наличие
серьезных проблем. Моделирование компиляции с Fortran H на машине Model 65 с
барабанами дало результат пять операторов в минуту! Анализ показал, что все
модели управляющей программы делали множество обращений к диску. Даже
интенсивно используемые модули супервизора часто обращались к диску, и
результат по звуку весьма напоминал шелест перелистываемой книги.
(C) Фредерик П.Брукс. Мифический человеко-месяц или как создатся программные системы
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Слушай, не надо, это уж совсем несерьезно. Персональный прокси-сервер, прокси для небольшой организации или тот прокси, через который, как утверждают, весь Китай в Интернет ходит (чтобы куда не надо не ходили) — это все же разные немного задачи ? Я что, должен сам додумывать ?
В настоящий момент на рынке присутствуют прокси-сервера, способные работать как персонально для одной машины, так и для крупных организаций. Вот такой и нужен.
PD>Уж точно. Потому как категорически отказываюсь разрабатывать не то гоночную машину , не то КАМАЗ. Оба они автомобили, как понимаешь..
А ты погляди на софт который тебя окружает.
AVK>>Потому что рынок.
PD>А, ну вот так и говори. С этм возражением я согласен, я уже писал об этом. Только будем честными перед собой — мы заранее заявляем. что делать будем не лучшим образом.
ЧТо такое лучшим образом? Время разработки это такой же критерий, не хуже и не лучше других.
PD>Только не надо при этом хоть самого себя обманывать. Надо честно в этом признаться
В чем признаваться то?
PD>Вот ответь прямо. Создали тебе идеальную ситуацию. Времени — сколько хочешь. Сроков нет. Специалистов — бери каких хочешь.
Такой ситуации не бывает.
AVK>>Вот мы и пришли к моменту, который ты упорно пытаешься игнорировать — жесткая привязка абстракций к реализации ведет к сильносвязным системам,
PD>Не ведет. Как ни реализуй модуль записи файлов в твоем прокси, от этого связность остальной части с этой компонентой не изменится.
Мы говорим не о реализациях, а об абстракциях. Согласно твоим утверждениям, абстрактная модель модуля записи файлов должна зависеть от его реализации.
>>что, в свою очередь резко уменьшает предсказуемость такой системы и резко же усложняет ее дальнейшую модификацию.
PD>Это почему ? На примере прокси, пожалуйста.
Почему высокая связность системы уменьшает предсказуемость и усложняет модификацию кода?
PD>Ну а если уж на то пошло, то в моей работе (о которой у теяб такие сомнения) от меня как раз и требовали обеспечить доступ к данным. Абстракции — не требовали, предельно оптимальный доступ — да. И именно это я делал.
Это не задача архитектора. Это задача оптимизатора.
>>а потом, по мере необходимости, мигрировать в узких местах к решениям более связным.
PD>А надо ли ?
Если эффективность не устраивает — надо.
PD> Если слабосвязанное решение оптимально по своим компонентам, а эффект от связи на порядок ниже чем от компонент, то оптимизировать надо ту компоненту, которая есть лимитирующая стадия процесса.
Внимательно читай. Я написал "мигрировать в узких местах".
PD>Ну вообще-то, конечно, может быть. А реально, ответь на примере твоего прокси — если , скажем, файловая часть будет сделана наилучшим образом, из-за чего вдруг возникнет узкое место на связи этой подсистемы с остальной частью ?
Легко. Ключ поиска в кеше стал включать, к примеру, еще и дату файла.
PD> И что надо сделать, если она возникнет ? Ухудшить эту часть ?
Рефакторинг.
>>Т.е., перефразируя, оптимизации по потреблению ресурсов сильно зависят от конкретного количества и соотношения этих ресурсовю
PD>Ну да, конечно. Поэтому-то я и возмутился, когда ты мне предложил абстрактный проки спроектировать.
Ты опять путаешь проектирование архитектуры и написание реализации.
AVK>>А зачем делать тесты, если можно сразу начать проектировать систему? Если, как ты утверждаешь, у тебя очень хорошая интуиция, то и переделывать потом ничего не придется.
PD>Неразумно. Моя интуиция — как я уже сказал, подсознательный прошлый опыт. Если он есть и я чувствую, что здесь можно ожидать (по прошлому опыту знаю) — тесты не нужны, конечно. Ну доведем до логического конца -я уже такое писал, для другой задачи, зачем мне тесты, когда я и так знаю, чего здесь можно ждать. Но в реальности это не всегда так, так что интуиция интуицией, а попробовать не мешает. Для того, чтобы интуиция не подвела.
Объясни мне простую вещь — а почему нельзя проводить тесты на реальном приложении? Пусть даже на начальном этапе оно недалеко от тестов ушло.
AVK>>А оно там было с первых версий?
PD>Понятия не имею.
Поинтересуйся.
AVK>>Устанавливать жесткие дедлайны до того, как будет получен работающий прототип — признак недалекого ума РМов.
PD>М-да... Заказчик-то срок установил.
Это проблемы заказчика. В любом случае — если мы начнем двигаться мелкими шажками-итерациями, то заказчик получит результат максимально быстро. А вот если мы назакладываемся в проектном решении на интуицию, а потом ошибемся, то перерасход времени будет дикий.
AVK>>Еще раз — чем тесты лучше прототипа?
PD>1. Очень дешевы.
Далеко не всегда. И, если само приложение грамотно спроектировано, эксперименты с реализациями куска будут не сильно дороже экспериментов с отдельным приложением. Зато не весь код потом пойдет в мусорную корзину, да еще и взаимосвязанные системы можно будет оттестировать.
AVK>>Массив сам такое не умеет. То, что ты написал называется список на массивах. И это тоже не абстракция. Речь же идет о выборе абстракций.
PD>Хм, не понял
А что тут непонятного? IList — абстракция. ArrayList, массив — реализация. Understand?
AVK>>Я тебе уже кажется говорил — хеш-таблица и список это разные вещи, они не взаимозаменяемы.
PD>А мне что в лоб, что по лбу. Мне данные хранить надо.
Вот и описывай абстрактное хранилище данных. При чем тут хеш-таблица?
PD> Доступ к ним — хорошо, если бы по индексу, это удобнее всего. Но если по индексу не удастся найти нужной реализации — ладно, по ключу доступ тоже сойдет Мне на высокие материи наплевать, мне не теория нужна, что там заменяемо, а что нет. Мне — что делать, ответь ?
Устранить разброд и шатание и определится, что же тебе все таки нужно — доступ по ключу или доступ по индексу. Или и то и другое. Нужен ли тебе порядок следования.
AVK>>Писать свою реализацию IList. А в чем проблема?
PD>Ну и ну! Заложили туда IList, а выяснилось, что ни одной приличной реализации нет. Писать свою будем.
А куда деваться, если ее нет?
PD> А рядом хеш-таблица и дерево , оба вполне годятся,
Не годятся. IList подразумевает сохранение порядка следования, хеш-таблица нет, хештаблица требует уникального ключа, IList нет и т.д. Если у тебя есть обощенные алгоритмы, рассчитанные на IList, то ни о какой эквивалентности списка и хеш-таблицы и речи идти не может. Если же у тебя обобщенные алгоритмы изолированны от хранилища, так и создай IAbstractStorage, а уж внутри него реализуй хранение как тебе нравится — через массив, список или хеш-таблицу. Удивительно, что такие базовые вещи приходится описывать, но иначе непонятно как указать тебе на явные нестыковки в том, что ты пишешь.
(Кстати, характерный момент — ты пытаешься иллюстрировать архитектурные тезисы кодом с указателями, да еще и с пометками, мол тут memcpy надо использовать.)
AVK>>Офигеть. Так у нас тут форум по строительству зданий оказывается. А я то думал ... Ну тогда как нибудь без меня, я в кирпичах не специалист, за всю свою жизнь только один дом и построил.
PD>Действительно офигеть можно. Человеку приводишь аналогию,
Аналогии приводятся в иллюстрацию. Ты чего хотел своей аналогией проиллюстрировать? Как не надо строить дома? Это имеет отношение к тому, о чем мы говорим? Мы о строительстве домов говорим?
PD> а он ее буквально понимает. Ладно, придется впредь с тобой аналогиями не пользоваться.
Не только со мной. Не надо вобще пользоваться аналогиями кроме как для иллюстрации.
PD>А может, и не надо продолжать. Позиции сторон ясны, согласовать их в главном невозможно.
Не знаю. Пока что я вижу, что ты опять путаешься в каких то базовых вещах.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет, в условиях, когда используется доп. память, я принципиально скорости не сравниваю. Даже если при этом лишние действия делаются. Только при равных условиях по памяти.
Так тебе шашочки или ехать?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>А просто по совету AndrewVK начали с прототипа. Не слишком заботясь о реализации. А в итоге там оказалось узкое звено. И его теперь иначе не расшить.
И что? Павел, мы получили прототип не за две недели до дедлайна, а через две недели от начала. Что там делать больше двух недель? Мы же свою ФС не пишем, как не пишем и свой стек протоколов. PD>А если ты скажешь, что надо было ПМ'у с самого начала думать — так Андрей же и утверждает, что пока не сделаем — это ясно не будет, не может быть.
Совершенно верно. Архитектор выписывает список рисков. И именно они проверяются в первую очередь, как только готова соответствующая часть прототипа.
>>Идея другая — мы создаем грубую модель, на основе которой грубо работающий прототип (с простейшей реализацией). Потом смотрим на него и получаем новую информацию — чего не учли, где ошиблись. И начинаем проблемные места перепроектировать и создавать уже боевую реализацию. Потом получаем второй прототип и процесс повторяем.
Совершенно верно. И под это заранее заложены оценки стоимости. И даже если на каком-то этапе мы понимаем, что очередной прототип разрабатывать уже экономически невыгодно, мы получили минимальные потери на неудачном проекте. В противоположном случае у нас есть риск оплатить разработку супероттюненой ФС, которая пойдет в корзину. Потому что остальная часть приложения так и не взлетела. PD>Кстати, вспомнил забавную историю на этот счет.
PD>Это они прототип системы сделали
Рекомендую также ознакомиться с приблизительной оценкой затрат на проект. Насколько я помню, Брукс приводит оценку около 5000 человеко-лет. Павел, положа руку на сердце, ты когда-нибудь участвовал в проекте стоимостью хотя бы в 50 человеко-лет?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Рекомендую также ознакомиться с приблизительной оценкой затрат на проект. Насколько я помню, Брукс приводит оценку около 5000 человеко-лет.
Угу. В 1965 году с перфокартами. Я бы мог многое на эту тему порассказать.
>Павел, положа руку на сердце, ты когда-нибудь участвовал в проекте стоимостью хотя бы в 50 человеко-лет?
Здравствуйте, Дарней, Вы писали:
Д>мы все уже трепещем
Трепещите
>>>Неплохо бы также узнать их мнение о твоем коде.
Д>ну я ведь просил отзывы других программистов, а не заказчика.
Это и есть отзыв человека, который непосредственно использовал мой код. Программиста. А заказчик (настоящий) о моем существовании даже и не знает — я с ним дела непосредственно не имел. Ему вообще не интересно , кто и что делал — у него другие проблемы
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Трепещите
и содрогнется ФП от очередного флейма, бессмысленного и беспощадного.
PD>Это и есть отзыв человека, который непосредственно использовал мой код. Программиста. А заказчик (настоящий) о моем существовании даже и не знает — я с ним дела непосредственно не имел. Ему вообще не интересно , кто и что делал — у него другие проблемы
Значит, это — просто посредник, который передает другим задания, в которых сам ничего не смыслит. Зачем тебе так хочется назвать его программистом?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[22]: Каков глубокий смысл сериализации? - в завершение
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В общем, из этой дискуссии мне более понятным стало то состояние дел, о котором я писал , когда говорил об эффективности. Сделаем что-нибудь, а потом будем это улучшать, пока не достигенм приемлемых характерстик...При таком подходе, естественно, ничего иного получиться не может.
Т.е. аргументы кончились, доказать ничего не вышло. Становимся в позу Оракула и начинаем вещать. Оракул, он, как известно, никогда свои слова доказательствами не подкрепляет, высшие силы доказательств давать не любят.
Здравствуйте, AndrewVK, Вы писали:
AVK>Т.е. аргументы кончились,
Силы кончились. И время тоже.
>доказать ничего не вышло.
Несомненно. Тебе. А другим — пусть сами решают. Я все сказал, что хотел.
>Становимся в позу Оракула и начинаем вещать. Оракул, он, как известно, никогда свои слова доказательствами не подкрепляет, высшие силы доказательств давать не любят.
Когда других аргументов нет — начинают такие применять. Что, впрочем, я от тебя и Sinclair не раз уже встречал.
А насчет оракулов — почитай историю Древней Греции. В особенности насчет Дельфийского оракула и его пророчества насчет "божественного Саламина". Тема — греко-персидские войны.
Здравствуйте, Дарней, Вы писали:
PD>>Это и есть отзыв человека, который непосредственно использовал мой код. Программиста. А заказчик (настоящий) о моем существовании даже и не знает — я с ним дела непосредственно не имел. Ему вообще не интересно , кто и что делал — у него другие проблемы
Д>Значит, это — просто посредник, который передает другим задания, в которых сам ничего не смыслит.
Как тебе хочется, чтобы это было так! Ну просто очень хочется! Невозможно же терпеть просто, если это иначе. Потому что тогда придется признать, что иначе бывает. Что не всегда проекты делают по принципу "что-нибудь сделаем и посмотрим, что из этого вышло". Что и по другому делают. И вполне удачно.
Разочарую — это не посредник. Это человек, написавший большУю часть кода и руководивший проектом.
>Зачем тебе так хочется назвать его программистом?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Как тебе хочется, чтобы это было так! Ну просто очень хочется! Невозможно же терпеть просто, если это иначе. Потому что тогда придется признать, что иначе бывает. Что не всегда проекты делают по принципу "что-нибудь сделаем и посмотрим, что из этого вышло". Что и по другому делают. И вполне удачно.
В условиях, когда требования к проекту определены заранее и намертво зафиксированы, а изменений в коде не предвидится в ближайший десяток лет? Бывает, конечно бывает! В таких условиях можно позволить себе любую прихоть, в том числе и сидеть месяц над листком бумаги и выдумывать, "где же оно там будет тормозить". Вместо того, чтобы сделать за неделю прототип и получить точные данные. В таких тепличных условиях надо вообще очень сильно постараться, чтобы запороть проект.
Но это — роскошь, которой не обладают (и никогда не будут обладать) 99,999% команд разработчиков. Поэтому просто глупо думать, что им подойдет такой же подход к работе.
PD>Разочарую — это не посредник. Это человек, написавший большУю часть кода и руководивший проектом.
Ну а саппортом твоего кода он занимался? Ты сам ответил — нет. Значит, это в любом случаем не является ответом на мой вопрос.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[24]: Каков глубокий смысл сериализации? - в завершение
Здравствуйте, Дарней, Вы писали:
Д>Ну а саппортом твоего кода он занимался? Ты сам ответил — нет. Значит, это в любом случаем не является ответом на мой вопрос.
Он его применял. Я его писал. Впрочем, иногда он изменения в него вносил. Когда я в отпуск уехал. Вернулся — посмотрел, что он там поменял. Принял, но мягко ему намекнул, что в дальнейшем будет лучше, если я сам этим буду заниматься.
(Послднее признание — специально для тебя. Чтобы у тебя был повод придраться к нему и меня упрекнуть)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Он его применял. Я его писал. Впрочем, иногда он изменения в него вносил. Когда я в отпуск уехал. Вернулся — посмотрел, что он там поменял. Принял, но мягко ему намекнул, что в дальнейшем будет лучше, если я сам этим буду заниматься.
Водить машину и ремонтировать ее — это таки очень разные вещи.
Мы уже победили, просто это еще не так заметно...
1.1.4 stable rev. 510
А хочется книжку...
