Я не намерен здесь обсуждать дотнет.
Я не намерен обсуждать сериализацию ни как идею, ни как автор ее использует. Тем более, что ниже по ветке приведено иное решение, с иными совсем характеристиками. Его я также не намерен обсуждать.
Я просто одну фразу хочу прокомментировать.
>Сериализация проходит за приемлемое время...Скажем, 3 милиона элементов Dictionary сериализуются за 2 минуты в файл размером 150 МБ.
Так вот.
Вывод данных в файл размером в 150 Мб , если данные уже готовы и находятся в ОП, должен производиться за несколько секунд.
А автор пишет — 2 минуты приемлемое время.
А что значит приемлемое ? Пользователя устраивает ? Видимо, да. Появляется какой-то там диалог с песочными часами, ждите 2 минуты... Пользователь доволен — все работает, ну а то, что приходится ждать 2 минуты — что же поделать, программа сложная, данных много (миллионы!), так что терпите. Вот 20 минут на десериализацию убедить пользователя подождать, видимо, уже не удается.
Вот к чему приводит этот критерий "качества", с позволения сказать.
Вот и имеем дело мы с таким "качественным" ПО. С Visual Studio, которая solution с парой проектов грузит десяток-два секунд. С Office или Open Office, который стартует десяток секунд.
Мы к этому уже привыкли. Это для нас приемлемо. Использовать мощность компьютера на 5-10% — это приемлемо.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мы к этому уже привыкли. Это для нас приемлемо. Использовать мощность компьютера на 5-10% — это приемлемо.
Предложи альтернативный критерий качества.
про bloatware, помнится, очень хорошо писал Вирт. Ну кто его послушал?
Видимо, быстрые программы станут писать, когда на рынке будут появляться аналогичные быстрые конкурентоспособные программы.
Соответственно они появятся, видимо, когда создадут альтернативное средство для их написания, которое по удобству сравнится .NET (хочется думать превзойдет и будет кроссплатформенным).
Про себя скажу — что сейчас все чаще пользуюсь Chrome именно из-за его быстроты и надежности.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Мы к этому уже привыкли. Это для нас приемлемо. Использовать мощность компьютера на 5-10% — это приемлемо. 0>Предложи альтернативный критерий качества.
Можно, например, прикидывать, сколько времени/ресурсов при выполнении занимает занимает оптимальная реализация на данном языке. И критерием будет, например, то чтобы текущая реализация занимала не более чем в два раза больше времени/ресурсов при выполнении, если нет более строгих критериев. Разница в производительности между приемлемой и оптимальной должна быть в разы, а не на несколько порядков.
Если же кажется, что сделать приемлемую реализацию на определенном языке чрезвычайно трудоемко, значит используется не тот язык.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я не намерен обсуждать сериализацию ни как идею, ни как автор ее использует. Тем более, что ниже по ветке приведено иное решение, с иными совсем характеристиками. Его я также не намерен обсуждать.
Это не проблема быстроты как таковой. Это проблема алгоритмов. Нельзя приспасабливать Dictionary к данным с таким объемом.
PD>А автор пишет — 2 минуты приемлемое время.
У меня один отчет генерился 2 часа. Но поскольку он был нужен очень редко, и чисто для отчетности — пользователя это устраивало. Мог ли я тогда кардинально увеличить скорость? Мог. Только не стал на это тратить свое время(а оно для пользователя недешевое). А потратил его на действительно ему нужные вещи.
Здравствуйте, A13x, Вы писали:
A>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>...
A>Про себя скажу — что сейчас все чаще пользуюсь Chrome именно из-за его быстроты и надежности.
У меня хром регулярно падает. Весь. Т.е. утаскивает за собой все вкладки. Потом предлагает их восстановить. И т.к. страница, на которой он падал, восстанавливается тоже, падает ещё раз. Опять же весь.
И, да. Из всех браузеров на меня хром жрёт больше всех оперативы. Это про bloatware.
"Приемлемо" — это соответствие поведения ПО предполагаемым сценариям использования.
Если к либе предлагается документация, в которой приведены ограничения по использованию, и эти ограничения выполняются, то это приемлемо.
Разработчик же перед принятием решения об использовании либы должен оценить приемлемость этих ограничений уже применительно к своему проекту.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вывод данных в файл размером в 150 Мб , если данные уже готовы и находятся в ОП, должен производиться за несколько секунд.
Т.е. даже если данные и их представление — абсолютно разные вещи, требуемые сложной конвертации? Мы же сейчас не о сериализации, правильно?
PD>Вот и имеем дело мы с таким "качественным" ПО. С Visual Studio, которая solution с парой проектов грузит десяток-два секунд. С Office или Open Office, который стартует десяток секунд.
Я, конечно, что-то делаю не так. Но за десяток-два секунд у меня загружается солюшен в 23 проекта, суммарным объёмом под миллион строк, проверяется репозиторий, и, если есть, то из него скачиваются последние версии нужных файлов. Вот последняя часть — наиболее лагающая.
Без сорс-контроля солюшен грузится не более 5 секунд. Солюшен из двух проектов грузится моментально. И это при том, что у меня стоит РеШарпер.
Здравствуйте, GlebZ, Вы писали:
GZ>Это не проблема быстроты как таковой. Это проблема алгоритмов. Нельзя приспасабливать Dictionary к данным с таким объемом.
Посмотри по ветке ниже, там есть решение с Dictionary и нормальной скоростью. Да и вообще я думаю, что практически из любой структуры в ОП вывод в файл 150 Мб должен происходить за несколько секунд.
Что касается алгоритмов — извини, Глеб, где ты тут увидел алгоритм ?
PD>>А автор пишет — 2 минуты приемлемое время. GZ>У меня один отчет генерился 2 часа. Но поскольку он был нужен очень редко, и чисто для отчетности - пользователя это устраивало.
См. выделенное. Не тот случай. Есть ядро программы и есть примочки. На примочки можно иногда и не обращать внимание, если их запускают раз в месяц.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Т.е. даже если данные и их представление — абсолютно разные вещи, требуемые сложной конвертации ?
Нет. Если требуется конвертация, то есть 2 задачи — конвертация и вывод отконвертированных данных в файл. Можно их хотя бы теоретически разделить (практически может быть, будет конвертироваться on fly). Оценить время на конвертацию я не могу, не зная ее характера. Но вот если данные (в виде набора битов уже в ОП — извольте в несколько секунд уложиться. Независимо от того, как они там представлены. А это именно тот случай.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Т.е. даже если данные и их представление — абсолютно разные вещи, требуемые сложной конвертации ?
PD>Нет. Если требуется конвертация, то есть 2 задачи — конвертация и вывод отконвертированных данных в файл. Можно их хотя бы теоретически разделить (практически может быть, будет конвертироваться on fly). Оценить время на конвертацию я не могу, не зная ее характера. Но вот если данные (в виде набора битов уже в ОП — извольте в несколько секунд уложиться. Независимо от того, как они там представлены. А это именно тот случай.
Неверно понял, извини. Тогда да — лимитом должно быть железо/ОС.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, A13x, Вы писали:
A>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>...
A>>Про себя скажу — что сейчас все чаще пользуюсь Chrome именно из-за его быстроты и надежности.
AS>У меня хром регулярно падает. Весь. Т.е. утаскивает за собой все вкладки. Потом предлагает их восстановить. И т.к. страница, на которой он падал, восстанавливается тоже, падает ещё раз. Опять же весь.
AS>И, да. Из всех браузеров на меня хром жрёт больше всех оперативы. Это про bloatware.
Это сейчас или пол года назад было? И на какой это системе? Просто интересно.
Здравствуйте, Aleх, Вы писали:
A>Можно, например, прикидывать, сколько времени/ресурсов при выполнении занимает занимает оптимальная реализация на данном языке. И критерием будет, например, то чтобы текущая реализация занимала не более чем в два раза больше времени/ресурсов при выполнении, если нет более строгих критериев. Разница в производительности между приемлемой и оптимальной должна быть в разы, а не на несколько порядков.
Обоснуй, почему надо использовать такой критерий.
Я вот к чему — критерии, танцующие "от клиента" имеют вполне понятную аргументацию. Пользователь платит деньги за продукт => если пользователю хорошо, то и разработчику хорошо. Если пользователь согласен платить за перформанс, то имеет смысл этим заниматься. Если пользователю пофиг на этот перформанс, то зачем тратить деньги на его оптимизацию? Кто будет за эту работу платить? Как обосновать необходимость этой оптимизации? Исключительно собственным инженерно-эстетическим чувством? Спорный момент.
Disclaimer: я не защищаю практику "тяп-ляп" решений, я ищу хорошую аргументацию.
Здравствуйте, Aleх, Вы писали:
A>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Здравствуйте, A13x, Вы писали:
A>>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>...
A>>>Про себя скажу — что сейчас все чаще пользуюсь Chrome именно из-за его быстроты и надежности.
AS>>У меня хром регулярно падает. Весь. Т.е. утаскивает за собой все вкладки. Потом предлагает их восстановить. И т.к. страница, на которой он падал, восстанавливается тоже, падает ещё раз. Опять же весь.
AS>>И, да. Из всех браузеров на меня хром жрёт больше всех оперативы. Это про bloatware.
A>Это сейчас или пол года назад было? И на какой это системе? Просто интересно.
Буквально сегодня. WinXP x32, Vista x32, Win7 x64 — по оперативе данные одни и те же.
Падал на ХР и семёрке, на висте я его посмотрел и выкинул — это домашняя машина, мне там настроенной фоксы хватает.
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, A13x, Вы писали:
A>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>...
A>>Про себя скажу — что сейчас все чаще пользуюсь Chrome именно из-за его быстроты и надежности.
AS>У меня хром регулярно падает. Весь. Т.е. утаскивает за собой все вкладки. Потом предлагает их восстановить. И т.к. страница, на которой он падал, восстанавливается тоже, падает ещё раз. Опять же весь.
AS>И, да. Из всех браузеров на меня хром жрёт больше всех оперативы. Это про bloatware.
я пользую хром на линуксе, без flash плагина. Ни разу еще не падал, даже самые первые беты работали стабильно.
Здравствуйте, A13x, Вы писали:
AS>>У меня хром регулярно падает. Весь. Т.е. утаскивает за собой все вкладки. Потом предлагает их восстановить. И т.к. страница, на которой он падал, восстанавливается тоже, падает ещё раз. Опять же весь.
AS>>И, да. Из всех браузеров на меня хром жрёт больше всех оперативы. Это про bloatware.
A>я пользую хром на линуксе, без flash плагина. Ни разу еще не падал, даже самые первые беты работали стабильно.
Да сколько угодно верю. Мне от этого ни тепло ни холодно. Стартовая реклама хрома была: "если что-то упадёт, это будет только одна вкладка". На практике получаем, что падаёт всё.
На страницах с флешем работает ок. Падает, в основном, на всяких френдлентах в ЖЖ и гуглоридерах.
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, Aleх, Вы писали: 0>Я вот к чему — критерии, танцующие "от клиента" имеют вполне понятную аргументацию. Пользователь платит деньги за продукт => если пользователю хорошо, то и разработчику хорошо. Если пользователь согласен платить за перформанс, то имеет смысл этим заниматься. Если пользователю пофиг на этот перформанс, то зачем тратить деньги на его оптимизацию?
Объясни, по каким критерием пользователь должен решить, устраивает его этот перфоманс или нет. Откуда он знает, каким он может быть ? Ему дали программу, которая выполняет основную операцию за 5 мин. Он ее запускает и идет пить кофе. А если бы она работала 10 секунд, он бы в день сделал в 10 раз больше. Но откуда ему знать, что такое возможно ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Объясни, по каким критерием пользователь должен решить, устраивает его этот перфоманс или нет. Откуда он знает, каким он может быть ? Ему дали программу, которая выполняет основную операцию за 5 мин. Он ее запускает и идет пить кофе. А если бы она работала 10 секунд, он бы в день сделал в 10 раз больше. Но откуда ему знать, что такое возможно?
Это хороший вопрос. Все зависит от ситуации пользователя. Вот я, например, однажды решил, что Файрфокс слишком сильно тормозит и перепрыгнул в Хром. Какими критериями я руководствовался? Наверное, чувством дискомфорта. Более обстоятельный клиент (например, организация) может подсчитать убытки от простоя сотрудников в следствие тормозов программы.
Я не утверждаю, что я предлагаю хороший критерий, к которому нельзя придраться. Можно. Просто это пример критерия как-то связанного с конкретными экономическими реалиями клиента, от которых можно "размотать" цепочку назад к требованиям по перформансу у программы.
Соответственно, хочется иметь хотя бы насколько же аргументированные альтернативы.
Обобщу вопрос: например, есть программа у которой есть определенный performance issue. Исправить его (переписав наивную реализацию на хорошую) будет стоить Х денег. Вопрос — как определить, надо ли эти Х денег тратить на исправление этого issue, или потратить их на что-то еще (например, на исправление ДРУГОГО performans isse )?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Посмотри по ветке ниже, там есть решение с Dictionary и нормальной скоростью. Да и вообще я думаю, что практически из любой структуры в ОП вывод в файл 150 Мб должен происходить за несколько секунд. PD>Что касается алгоритмов — извини, Глеб, где ты тут увидел алгоритм ?
Как где? Там. Проблема в том, что при эффективности доступа у хеш таблиц трудно с добавлением. А у стандартного, основаного на перехешировании, совсем плохо. На что собственно наткнулись, и что собственно и исправили в самом решении (увеличением capacity). Соответвенно, разница геометрическая (как и положено при алгоритмической оптимизации).
PD>См. выделенное. Не тот случай. Есть ядро программы и есть примочки. На примочки можно иногда и не обращать внимание, если их запускают раз в месяц.
Ну дык напиши например в Microsoft — то что ваш офис фигня так как она очень трудно загружается. Правда при этом не забудь, что загрузка второго процесса, или повторная загрузка ворда уже не так тормозит.
Меня это не сильно колышит, поскольку обычно у меня несколько открытых файлов постоянно. Но если ты это напишешь в Microsoft, и таких писем будет множество, то они сделают энту быструю загрузку. С Windows 2000 это как то прокатило. Хрюша загружалась уже быстро согласно рекламным обещаниям корпорации.
