Здравствуйте, Flem1234, Вы писали:
PD>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
F>Не хотите статью на rsdn написать? Это новое слово в разработке требований.
Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.
F>И что, всегда требования производительности более важны, чем функции системы?
А кто сказал, что функции не важны или менее важны ? Я ? Ссылку!
>Ну, типа, если есть хоть малейший шанс увеличить производительность, то мы ее увеличиваем, а не добавляем новые фичи?
Зависит от задачи. Иногда новые фичи просто не нужны, а надо ускорить обработку.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
F>>Не хотите статью на rsdn написать? Это новое слово в разработке требований.
PD>Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.
Ухты! real-time приложения! Круто! Если "решения нет за фиксированное время — решения нет" верно, значит быстродействие входит в число функциональных требований. Если "я сегодня не завтракал" верно, то 2*2=5! Еще круче!
F>>И что, всегда требования производительности более важны, чем функции системы?
PD>А кто сказал, что функции не важны или менее важны ? Я ? Ссылку!
В том, что вы написали разобраться трудновато, то все же
PD>>У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.
Ну, вот перед вами 3 функции и требование чтобы никакая из них не выполнялась медленнее 2х секунд. Максима всегда такая, сделайте быстрее, если сможете. Т.е. пока вы окончательно не уперлись в предел своей квалификации, вы их не закончите? Заказчик спрашивает: "когда закончишь", а вы ему: "у нас есть еще 5 способов, которые могут повысить производительность на 2%". Заказчик: "О чём речь, делайте!"
>>Ну, типа, если есть хоть малейший шанс увеличить производительность, то мы ее увеличиваем, а не добавляем новые фичи?
PD>Зависит от задачи. Иногда новые фичи просто не нужны, а надо ускорить обработку.
А не могли бы отдельным постом в корне форума написать, как у вас обычно происходит разработка нового проекта, от идеи до развертывания? Видимо у вас очень специфический опыт, который идет в разрез с опытом подавляющего большинства
Здравствуйте, Flem1234, Вы писали:
F>Ухты! real-time приложения! Круто! Если "решения нет за фиксированное время — решения нет" верно, значит быстродействие входит в число функциональных требований. Если "я сегодня не завтракал" верно, то 2*2=5! Еще круче!
М-да... Если человек не хочет понять , что ему говорят — тут уже ничем не поможешь.
F>В том, что вы написали разобраться трудновато, то все же
PD>>>У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.
Все верно.
F>Ну, вот перед вами 3 функции и требование чтобы никакая из них не выполнялась медленнее 2х секунд. Максима всегда такая, сделайте быстрее, если сможете. Т.е. пока вы окончательно не уперлись в предел своей квалификации, вы их не закончите? Заказчик спрашивает: "когда закончишь", а вы ему: "у нас есть еще 5 способов, которые могут повысить производительность на 2%". Заказчик: "О чём речь, делайте!"
Похоже . Именно этим мы и занимаемся. Просто тебе не доводилось иметь дело с проектами такого рода, вот тебя и удивляет.
F>А не могли бы отдельным постом в корне форума написать, как у вас обычно происходит разработка нового проекта, от идеи до развертывания?
Нет, не буду .
>Видимо у вас очень специфический опыт, который идет в разрез с опытом подавляющего большинства
Да, это очень непохоже на разработку сайтов и т.п.
Здравствуйте, Flem1234, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
F>>>Не хотите статью на rsdn написать? Это новое слово в разработке требований.
PD>>Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.
F>Ухты! real-time приложения! Круто! Если "решения нет за фиксированное время — решения нет" верно, значит быстродействие входит в число функциональных требований. Если "я сегодня не завтракал" верно, то 2*2=5! Еще круче!
Здесь Павел прав, если я правильно его понимаю. Требования к максимальному отклику тех или иных компонентов системы вполне могут быть внесены в функциональные требования в том случае, если их невыполнение делает ничтожными значительную часть функционала системы, либо если этот параметр определяет непосредственно функциональность системы (например, если система предоставляет функционал по взаимодействию сторонних систем в режиме реального времени).
Точно так же, как и требования по безопасности (в большинстве случаев, входящие в НФТ), могут и должны быть вынесены в ФТ в случае разработки систем безопасности и противодействия информационным угрозам (IDS, FW, антивирусы и т.п.)
KV>Здесь Павел прав, если я правильно его понимаю. Требования к максимальному отклику тех или иных компонентов системы вполне могут быть внесены в функциональные требования в том случае, если их невыполнение делает ничтожными значительную часть функционала системы, либо если этот параметр определяет непосредственно функциональность системы (например, если система предоставляет функционал по взаимодействию сторонних систем в режиме реального времени).
Это даже и для realtime может быть верно. В сущности, требование по скорости присутствует практически всегда. Программа, решающая NP-полную задачу при N=1000, нефункциональна, что бы она не делала, так как увидеть ее функциональность никому не дано. Но и сайт, который дает ответ через 5 минут, тоже в большинстве случаев нефункционален, так как на него пользователь зайдет только один раз. А в других случаях вполне функционален. Вполне возможен web-севис, которому ставят в очередь задания, а он дает ответы через часы, потому что быстрее там не посчитаешь. Сам как-то принимал участие в такой разработке.
Другое дело, что это требование может быть не очень высоким , а поэтому незаметным для разработчика (все сойдет
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здесь Павел прав, если я правильно его понимаю. Требования к максимальному отклику тех или иных компонентов системы вполне могут быть внесены в функциональные требования в том случае, если их невыполнение делает ничтожными значительную часть функционала системы, либо если этот параметр определяет непосредственно функциональность системы (например, если система предоставляет функционал по взаимодействию сторонних систем в режиме реального времени).
KV>Точно так же, как и требования по безопасности (в большинстве случаев, входящие в НФТ), могут и должны быть вынесены в ФТ в случае разработки систем безопасности и противодействия информационным угрозам (IDS, FW, антивирусы и т.п.)
Тогда я не понимаю. Функциональное требование, это то, что должна делать система.
Пример: система выдает список заказов — функциональное требование. Но очень важно, что время выполнение этой функции не более 2х секунд. Это нефункциональное требование.
Если есть важное нефункциональное требование, вроде времени в системах реального времени, то это не делает его автоматически функциональным.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не знаю, что там буржуи делают, но если ты увеличиваешь ресурсы (железо и т.д.), то это называется именно увеличением ресурсов, а не оптимизацией программы. Покупая новые ресурсы, можно все что угодно усилить.
Это не так просто, как ты думаешь. Для интереса — можешь сам попробовать.
Здравствуйте, fmiracle, Вы писали:
F>Это не так просто, как ты думаешь. Для интереса — можешь сам попробовать.
А я и не говорил, что это просто. И пробовать мне не надо — я этим (распараллеливанием) в том числе и занимаюсь. Но это не имеет отношения к оптимизации алгоритма как такового. К примеру, мне удалось повысить его примерно в 3 раза, избавившись путем аналитических преобразований от квадратного корня, стоявшего в двойном цикле. Вот это решение — не зависит от ресурсов.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается. F>>Не хотите статью на rsdn написать? Это новое слово в разработке требований. PD>Этому новому слову лет так 50. Почитай, к примеру, про real-time приложения, если нет реакции за фиксированное время — решения нет.
Я тебе уже писал, что у тебя ошибка в том, что ты считаешь нефункциональные требования несущественными.
Это не так.
Система, не удовлетворяющая всему списку требований, не может быть принята в работу(*), вне зависимости от того, функциональные это требования или нефункциональные.
(*) — в некоторых случаях, если никак не удается уложиться в требования, могут быть пересмотрены требования, но сстема ве равно принимается когда она удовлетворяет всем требованиям.
Здравствуйте, fmiracle, Вы писали:
F>Я тебе уже писал, что у тебя ошибка в том, что ты считаешь нефункциональные требования несущественными. F>Это не так.
Где я такое утверждал ? Ссылку в студию.
F>Система, не удовлетворяющая всему списку требований, не может быть принята в работу(*), вне зависимости от того, функциональные это требования или нефункциональные.
Верно.
F>(*) — в некоторых случаях, если никак не удается уложиться в требования, могут быть пересмотрены требования, но сстема ве равно принимается когда она удовлетворяет всем требованиям.
Твое высказывание, если его перефразировать, звучит так. Система должна удовлетворять всем требованиям, но если она им не удовлетворяет, то требования иногда изменяют так, чтобы система им удовлетоворяла . Бывает, не спорю.
Выделено ниже — мной
'The 12 bugs of Christmas'
For the first bug of Christmas, my manager said to me
See if they can do it again.
For the second bug of Christmas, my manager said to me
Ask them how they did it and
See if they can do it again.
For the third bug of Christmas, my manager said to me
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the fourth bug of Christmas, my manager said to me
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the fifth bug of Christmas, my manager said to me
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the sixth bug of Christmas, my manager said to me
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the seventh bug of Christmas, my manager said to me
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the eighth bug of Christmas, my manager said to me
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the ninth bug of Christmas, my manager said to me
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the tenth bug of Christmas, my manager said to me Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the eleventh bug of Christmas, my manager said to me Say it's not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
For the twelfth bug of Christmas, my manager said to me Tell them it's a feature
Say it's not supported
Change the documentation
Blame it on the hardware
Find a way around it
Say they need an upgrade
Reinstall the software
Ask for a dump
Run with the debugger
Try to reproduce it
Ask them how they did it and
See if they can do it again.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Не знаю, что там буржуи делают, но если ты увеличиваешь ресурсы (железо и т.д.), то это называется именно увеличением ресурсов, а не оптимизацией программы. Покупая новые ресурсы, можно все что угодно усилить.
Типичное заблуждение. Всё что угодно усилить можно только бесконечно усиливая возможности одной единственной железки. Но эта величина у нас ограничена. Масштабирование — это как раз и есть оптимизация твоей программы для работы в распределённой среде.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>оставит исходный алгоритм практически в неизменном виде PD>Во имя чего ?
Во имя простоты и гибкости кода.
IT>>Теперь я тебе задам вопрос. Давай прямо — для файла с заранее известным небольшим размером в пределах нескольких десятков килобайт и в местах не критичных по производительности — ты по-прежнему утверждаешь, что будешь заниматься выжиманием производительности? Да или нет ?
PD>Конечно, нет, даже странно такой вопрос от тебя получить. Я же об этом сто раз писал. Вот, например PD>http://rsdn.ru/forum/philosophy/3605179.1.aspx
И как ты решишь задачу для небольшого файла.
PD>И в других местах писал, просто искать лень. Ты берешься опровергать мои высказывания, а ведь ты даже не поянл мою концепцию. А она проста
PD>Я не сторонник универсальных решений. Я за то, чтобы решения принимались с учетом конкретной ситуации. Одна и та же задача (тот же парсинг файла, к примеру) может потребовать разных решений в зависимости от объема обрабатываемых данных, возможности или невозможности распараллеливания, требований к памяти, времени и т.д. И именно с учетом всех этих факторов ее и надо решать.
Эта твоя концепция ущербна тем, что в ней не детерминирована величина объёма данных и каждый может это понимать по своему. Тем не менее универсальное решение найти можно для гораздо большего диапазана задач, чем тебе кажется, а для ещё большего диапазона универсальное решение может оказаться вполне приемлемым.
Мне доводилось в своё время заниматься обработкой гигабайтных файлов в реальных задачах. Так вот, по-быстрому написанный парсиг файла у меня занимал порядка 20 секунд. Медленно? Медленно. Но по-быстрому написанная последующая обработка полученных данных занимала больше суток. После всех оптимизаций удалось ужать это время до 40-ка минут. Как ты думаешь, если бы я занялся оптимизацией скорости парсинга, мне бы это сильно помогло?
PD>Да и вообще, если уж на то пошло
PD>string GetLastLine(string fileName) PD>{ PD>// ... PD>}
А теперь подумай, почему Майкрософт не вглючила такую замечательную функция во фреймворк.
PD>Вот тебе универсальное решение . Внутренности — по ситуации и задаче. Хочешь написать там ReadAllLines + Split — пиши. Надо иначе — перепишем ее иначе, остальной код никак не пострадает, даже если там внутри сначала появится энумератор, потом аккумулятор, а в конечном итоге трансформатор . Из-за чего шум-то весь ? Из-за чего такая гордость однострочным 10-секундным решением ? Только из-за того, что я еще одну строку написал и две фигурные скобки ?
А, вот ты о чём. Тогда понятно. Тебе нужно покурить хотя бы вот эту
Здравствуйте, samius, Вы писали:
S>Вернет последнюю строку если хватит памяти чтобы затолкать все строки. Единственная проблема ReadAllLines в том, что он читает все строки файла за раз и возвращает массив. Возвращал бы IEnumerable через yield return — не было бы проблем.
Наконец-то в 4-м фрейморке это дела пофиксят, добавив File.ReadLines. И memory-mapped files добавят. Не то чтобы раньше это все самостоятельно не решалось, но удобно что в самом фрейморке будет.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Pavel Dvorkin, Вы писали:
>>>оставит исходный алгоритм практически в неизменном виде PD>>Во имя чего ?
IT>Во имя простоты и гибкости кода.
Слишком дорогая плата. ИМХО.
IT>>>Теперь я тебе задам вопрос. Давай прямо — для файла с заранее известным небольшим размером в пределах нескольких десятков килобайт и в местах не критичных по производительности — ты по-прежнему утверждаешь, что будешь заниматься выжиманием производительности? Да или нет ?
PD>>Конечно, нет, даже странно такой вопрос от тебя получить. Я же об этом сто раз писал. Вот, например PD>>http://rsdn.ru/forum/philosophy/3605179.1.aspx
ReadAllLines, конечно, не будет, тем более что и ни к чему их все куда-то в ОП заносить. Читать до конца, взять последнюю строчку...
PD>>Я не сторонник универсальных решений. Я за то, чтобы решения принимались с учетом конкретной ситуации. Одна и та же задача (тот же парсинг файла, к примеру) может потребовать разных решений в зависимости от объема обрабатываемых данных, возможности или невозможности распараллеливания, требований к памяти, времени и т.д. И именно с учетом всех этих факторов ее и надо решать.
IT>Эта твоя концепция ущербна тем, что в ней не детерминирована величина объёма данных и каждый может это понимать по своему.
Если его квалификация высокая, то поймет правильно. А если нет — может, хоть задумается над своми универсальными решениями. Хоть мысль в голову придет — а не делаю ли я во много раз хуже, не подумав как следует, а применив универсальное решение, которое, может быть, именно здесь и не подходит.
>Тем не менее универсальное решение найти можно для гораздо большего диапазана задач, чем тебе кажется, а для ещё большего диапазона универсальное решение может оказаться вполне приемлемым.
Что мне кажется и что не кажется — ты знать не можешь . А по сущетсву —
1. Да, найти можно
2. Да, может оказаться приемлемым
Как видишь, я с тобой согласен. Но
3. Необходимо оценить, является ли оно приемлемым.
Если п.3 проходит, при любых (разумных) предположениях об изменениии данных — а почему бы и нет ? Но это доказать надо! Хотя бы самому себе.
IT>Мне доводилось в своё время заниматься обработкой гигабайтных файлов в реальных задачах. Так вот, по-быстрому написанный парсиг файла у меня занимал порядка 20 секунд. Медленно? Медленно.
Не знаю. Может, очень медленно, а может, очень быстро. Гигабайтные — это 1 Гб или несколько, это, как понимаешь, не все равно. Что за парсинг — ты не сообщил. Так что медленно или нет — судить не могу. Ты сам сказал, что медленно.
>Но по-быстрому написанная последующая обработка полученных данных занимала больше суток. После всех оптимизаций удалось ужать это время до 40-ка минут. Как ты думаешь, если бы я занялся оптимизацией скорости парсинга, мне бы это сильно помогло?
Скорее всего нет. Но опять же я прав — истина конкретна. Иногда нужно пренебречь неэффективностью из-за того, что писать эффективно здесь не имеет смысла по разным причинам. Иногда надо выжимать все, что можно.
PD>>Да и вообще, если уж на то пошло
PD>>string GetLastLine(string fileName) PD>>{ PD>>// ... PD>>}
IT>А теперь подумай, почему Майкрософт не вглючила такую замечательную функция во фреймворк.
Ну не смеши. Если бы уж включать, то
string GetLine(string fileName, int number)
Эта функция бы вполне могла пригодиться. А GetLastLine просто почти никому не нужна, кроме топикстартера в том топике.
Но и GetLine они не включили. А вот теперь к тебе вопрос — почему ? Вот есть TextReader, в нем ReadLine следующую есть, а по номеру — нет.
PD>>Вот тебе универсальное решение . Внутренности — по ситуации и задаче. Хочешь написать там ReadAllLines + Split — пиши. Надо иначе — перепишем ее иначе, остальной код никак не пострадает, даже если там внутри сначала появится энумератор, потом аккумулятор, а в конечном итоге трансформатор . Из-за чего шум-то весь ? Из-за чего такая гордость однострочным 10-секундным решением ? Только из-за того, что я еще одну строку написал и две фигурные скобки ?
IT>А, вот ты о чём. Тогда понятно. Тебе нужно покурить хотя бы вот эту
P.S. В институтах такому точно не учат. Ты еще пока не классик, чтобы твое личное мнение было необходимо изучать. Кстати, и рекомендовать свои собственные рассуждения для обязательного прочтения ("Тебе нужно покурить") как бы это сказать... не совсем этично. Рекомендовать можно что-то не свое, а твои статьи пусть кто-то другой порекомендует, если сочтет стоящим того.
With best regards
Pavel Dvorkin
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, CreatorCray, Вы писали:
CC>Я совершенно разделяю возмущение по поводу описанной баги, но не вижу необходимости в тотальном запрете инструмента только потому, что далеко не все умеют им безопасно пользоваться.
Да бредовый пример, который конкретно к С/С++ никаким боком. Такой же ляп можно создать на большинстве современного мейнстрима и даже на обоих версиях VB.
Здравствуйте, IT, Вы писали:
IT>Типичное заблуждение. Всё что угодно усилить можно только бесконечно усиливая возможности одной единственной железки.
А также более эффективным способом используя эту самую железку. Или ты считаешь такое в принципе неверным путем ? А почему, собственно ? Если я смогу при том же железе вычислять в 2 раза быстрее, чем сейчас, то мне понадобится в 2 раза меньше железок. И что тут плохого ?
>Но эта величина у нас ограничена. Масштабирование — это как раз и есть оптимизация твоей программы для работы в распределённой среде.
Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет. Ты вот, не покупая новые ресурсы сделай, тогда и хвались.
Вот есть у тебя, к примеру, грузовик. На нем можно перевезти, скажем, домашнюю мебель. Если ее аккуратно поставить, то за одну поездку раз можно, а если валом валить, то за 3 поездки получится. А ты предлагаешь — давайте валом валить, но купим еще 2 грузовика.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет.
Ежу, конечно, понятно, но на самом деле это не так. Точнее — далеко не всегда так. Очень сильно зависит от того, как написана программа. Скорость может просто не увеличиться (очень распространенный случай), а может и (хо-хо) серьезно замедлиться.
Это если мы по-прежнему говорим про распараллеливание по различным машинам (или хотя бы процессорам в одной машине). В рамках нарастания мощностей одной однопроцессорной одноядерной машины все, конечно, шоколадно, но к потолку их возможностей мы уже подошли.
Здравствуйте, fmiracle, Вы писали:
PD>>Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет.
F>Ежу, конечно, понятно, но на самом деле это не так. Точнее — далеко не всегда так. Очень сильно зависит от того, как написана программа. Скорость может просто не увеличиться (очень распространенный случай), а может и (хо-хо) серьезно замедлиться.
Совершенно верно. Однако если программа написана так. что при увеличении количества ресурсов ее скорость не увеличивается — под сомнением компетентность автора. В N раз она может не увеличиться, но в общем, должна.
F>Это если мы по-прежнему говорим про распараллеливание по различным машинам (или хотя бы процессорам в одной машине). В рамках нарастания мощностей одной однопроцессорной одноядерной машины все, конечно, шоколадно, но к потолку их возможностей мы уже подошли.
Смотря где и смотря в чем. Все не так просто. Например, если скорость лимитируется работой с диском, и можно уменьшить объем обмениваемых данных за счет их более рациональной организации, то можно выиграть прилично. Можно косвенно влиять на количество page faults за счет более продуманного алгоритма, меньше будет свопинга. И т.д.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Во имя чего ? IT>>Во имя простоты и гибкости кода. PD>Слишком дорогая плата. ИМХО.
Ну здрасте. Слишком дорогая плата — это пол процента производительности за раздутый всеми возможными оптимизациями код. А простота и гибкость очень быстро окупаются.
IT>>И как ты решишь задачу для небольшого файла. PD>ReadAllLines, конечно, не будет, тем более что и ни к чему их все куда-то в ОП заносить. Читать до конца, взять последнюю строчку...
Т.е. цикл, проверка символа возврата коретки, сохранение последней найденной позиции, откат к ней, опять читаем до конца... В общем императивного кода на порядок больше. В 10 секунд не уложишься.
IT>>Эта твоя концепция ущербна тем, что в ней не детерминирована величина объёма данных и каждый может это понимать по своему. PD>Если его квалификация высокая, то поймет правильно. А если нет — может, хоть задумается над своми универсальными решениями. Хоть мысль в голову придет — а не делаю ли я во много раз хуже, не подумав как следует, а применив универсальное решение, которое, может быть, именно здесь и не подходит.
Ты говоришь об одном проценте случаев, причём эти случаи видны из далека, как правило ещё на этапе проектирования.
PD>Как видишь, я с тобой согласен. Но PD>3. Необходимо оценить, является ли оно приемлемым.
Ну оцени, в чём проблема? Это сделать совсем не сложно при условии внятной постановки задачи.
IT>>Мне доводилось в своё время заниматься обработкой гигабайтных файлов в реальных задачах. Так вот, по-быстрому написанный парсиг файла у меня занимал порядка 20 секунд. Медленно? Медленно.
PD>Не знаю. Может, очень медленно, а может, очень быстро. Гигабайтные — это 1 Гб или несколько, это, как понимаешь, не все равно. Что за парсинг — ты не сообщил. Так что медленно или нет — судить не могу. Ты сам сказал, что медленно.
Я тебе сообщил другую, гораздо более важную вещь — скорость в рамках решения всей задачи оказалась более чем приемлемой. Неужели это тебе до сих пор не понятно?
>>Но по-быстрому написанная последующая обработка полученных данных занимала больше суток. После всех оптимизаций удалось ужать это время до 40-ка минут. Как ты думаешь, если бы я занялся оптимизацией скорости парсинга, мне бы это сильно помогло?
PD>Скорее всего нет. Но опять же я прав — истина конкретна. Иногда нужно пренебречь неэффективностью из-за того, что писать эффективно здесь не имеет смысла по разным причинам. Иногда надо выжимать все, что можно.
Вообще-то, ты при любом удобном случае утверждаешь совсем другое — не иногда, а всегда надо выжимать всё, что можно. Но то, что ты сейчас сказал я занесу в избранное, как раз для того, чтобы тебе об этом в дальнейшем по-чаще напоминать.
PD>>>Да и вообще, если уж на то пошло
PD>>>string GetLastLine(string fileName) PD>>>{ PD>>>// ... PD>>>}
IT>>А теперь подумай, почему Майкрософт не вглючила такую замечательную функция во фреймворк. PD>Ну не смеши. Если бы уж включать, то PD>string GetLine(string fileName, int number) PD>Эта функция бы вполне могла пригодиться. А GetLastLine просто почти никому не нужна, кроме топикстартера в том топике. PD>Но и GetLine они не включили. А вот теперь к тебе вопрос — почему ? Вот есть TextReader, в нем ReadLine следующую есть, а по номеру — нет.
По той же причине, по которой я тебя рассмешил — это нафиг никому не надо, а кому вдруг ну очень сильно понадобиться делается за три минуты на коленке.
IT>>А, вот ты о чём. Тогда понятно. Тебе нужно покурить хотя бы вот эту
статью. Жаль, что этому в институтах не учат. В вашем наверняка тоже нет.
PD>Батенька, у тебя просто память отказывает. Мне ее курить не надо, я ее прекрасно помню и свои возражения на нее тоже.
PD>P.S. В институтах такому точно не учат. Ты еще пока не классик, чтобы твое личное мнение было необходимо изучать. Кстати, и рекомендовать свои собственные рассуждения для обязательного прочтения ("Тебе нужно покурить") как бы это сказать... не совсем этично. Рекомендовать можно что-то не свое, а твои статьи пусть кто-то другой порекомендует, если сочтет стоящим того.
Я не рекомендую, я даю ссылку и предлагаю хоть немного задуматься, т.е. "покурить" написанное. При вдумчивом, неспешном прочтении и длительном размышлении над прочитанным обещаю просветление, после которого советы оптимизировать всё и вся покинут тебя навсегда.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Типичное заблуждение. Всё что угодно усилить можно только бесконечно усиливая возможности одной единственной железки.
PD>А также более эффективным способом используя эту самую железку. Или ты считаешь такое в принципе неверным путем ? А почему, собственно ? Если я смогу при том же железе вычислять в 2 раза быстрее, чем сейчас, то мне понадобится в 2 раза меньше железок. И что тут плохого ?
Ну увеличил ты в два раза, что дальше? После этого увеличишь в 0.2 раза, а потом в 0.02 раза, а потом в 0.002 раза? Каждое новое увеличение будет на порядок меньше, а стоить будет на порядок дороже. С масштабированием стоимость увеличения равна стоимости железа.
PD>Еще раз — я веду речь про оптимизацию при данных ресурсах. При увеличении числа ресурсов скорость возрастет, это ежу понятно, пусть не в N раз, но возрастет. Ты вот, не покупая новые ресурсы сделай, тогда и хвались.
Я? Похвалиться? Да скока угодно. Смотрим внимательно сюда.
На картинке результаты теста производительности ORM tools.
Весь зелёненький, чемпион в лёгком и тяжёлом весе — BLToolkit, самый быстрый ORM в мире. Моя работа с сотоварищами. Как видишь инструменты от MS, NH и пр. тихо покуривают в сторонке.
А ты можешь чем нибудь похвалиться?
Впрочем, можешь не отвечать. Пиписькомерство мне не интересно. Даже делая самые производительные инструменты, я настаиваю на том, что преждевременные оптимизации, о которых ты не устаёшь повторять вновь и вновь — это зло.
PD>Вот есть у тебя, к примеру, грузовик. На нем можно перевезти, скажем, домашнюю мебель. Если ее аккуратно поставить, то за одну поездку раз можно, а если валом валить, то за 3 поездки получится. А ты предлагаешь — давайте валом валить, но купим еще 2 грузовика.
Тебе, конечно, виднее. Но я предпочитаю доверять перевозку моей мебели профессионалам, а не любителям.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
