LVV>>В ваших рассуждениях только один минус — не видать что-то рисовалок, рестартующих после краха... PD>А Word восстанавливает документ после краха. Open Office тоже. И более или менее успешно. FireFox после краха восстанавливает все табы.
Это как раз из той оперы, что на безрыбье и рак — рыба... По мне так лучше бы он вообще не падал... Ну а раз упал, тогда чтоб не было потерь...
В общем, понятно, что требования и к надежности, и к эффективности определяются при разговоре с заказчиком.
При этом, очевидно, заявления типа"чтоб работало максимально быстро" — требованиями не являются...
И еще одно соображение по эффективность...
Сначала занимаются скоростью. Памятью занимаются только тогда, когда ее не хватает...
Но и скорость может иметь обратный психологиченский эффект (об этом писали), когда слишком быстрый ответ системы у простого пользователя вызывает эффект комплекса неполноценности из-за разница в скорости коммуникаций...
Поэтому резюме ИМХО.
Твой приоритет эффективности определен не твоими вкусами и предпочтениями, а постоянными требованиями заказчика или характером задачи....Если б не требовали, то и упираться б в эффективность слишком не стал бы... А вот ошибки б — исправлял бы всегда...
Если б писал лично для себя...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Это как раз из той оперы, что на безрыбье и рак — рыба... По мне так лучше бы он вообще не падал... Ну а раз упал, тогда чтоб не было потерь...
+1
LVV>В общем, понятно, что требования и к надежности, и к эффективности определяются при разговоре с заказчиком. LVV>При этом, очевидно, заявления типа"чтоб работало максимально быстро" — требованиями не являются...
Не согласен.
LVV>И еще одно соображение по эффективность... LVV>Сначала занимаются скоростью. Памятью занимаются только тогда, когда ее не хватает...
Тоже не согласен. Если текстовый редактор будет работать очень быстро и хорошо, но займет 1 Гб — я его выброшу. Хоят у меня 2 Гб на машине. Но есть и другие приложения, их список неопределен, а поэтому надо брать памяти как можно меньше, чтобы и другим осталось.
LVV>Но и скорость может иметь обратный психологиченский эффект (об этом писали), когда слишком быстрый ответ системы у простого пользователя вызывает эффект комплекса неполноценности из-за разница в скорости коммуникаций...
Ну замедлить-то как-нибудь сможем, если надо. А во-вторых, я говорил в основном отнюдь не о скорости взаимодействия с пользователем, а о скорости обработки данных.
LVV>Поэтому резюме ИМХО. LVV>Твой приоритет эффективности определен не твоими вкусами и предпочтениями, а постоянными требованиями заказчика или характером задачи....
Совершенно верно. Я его никому не навязываю. Но и мне не надо иные навязывать (это не к тебе относится). И не надо иные принципы выставлять в качестве универсально — обязательных.
>Если б не требовали, то и упираться б в эффективность слишком не стал бы...
Стал бы. Привычка
>А вот ошибки б — исправлял бы всегда...
Ну это уж да.
LVV>Если б писал лично для себя...
Эх...
With best regards
Pavel Dvorkin
Re[2]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, VladD2, Вы писали:
VD>Что до свободы делать что хочет Дворкин, то у него просто довольно странные желания. Лично мне хочется побыстрее написать программу которая будет работать надежно, стабильно и при этом с приемлемой (а не максимально возможной) производительностью. И я не хочу траха. А вот люди вроде Дворкина считаю, что максимальная производительность — это главный приоритет перекрывающий все остальне. Плюс Дворкин фактически заперт в миру идеом С/С++ и просто не представляет как писать софт по другому. Так что от части его свобода только ему кажется свободой, а на самом деле — это клетка.
Хочу от себя подкорректировать — это зашоренность мышления, когда человек смотрит на мир сквозь какой-то ментальный аналог трафарета.
Здравствуйте, kochetkov.vladimir, Вы писали:
PD>>Нет, все как раз наоборот. У меня проблемы со стиркой белья, вода извне в машину не течет, а изнутри вытекает на пол, ротор не крутится и т.п, а тут ко мне приходят и говорят : "Мы знаем, что вам нужно, и именно сейчас! Мы решим все ваши проблемы. Самая лучшая кофеварка от фирмы Идиотекс!!! Только у нас!"
KV>А ты теперь поставь себя на их место: они к тебе приходят с классной кофеваркой и видят как чел варит кофе в стиральной машине...
Самое печальное, что, однако, очень часто случается в IT (тут я ни на кого пальцем не показываю), это когда человек в стиральной машине варит кофе, но при этом твердо убежден, что он стирает белье... В этом случае предложение воспользоваться кофеваркой просто в принципе не может найти понимания.
Здравствуйте, CreatorCray, Вы писали:
CC>Пример из жизни: пришел биг босс и сказал что заказчик хочет и платит. CC>Всё. Все остальные рассуждалки "да каму ета наааада" в сад.
Ну, значит написание драйверов устройств под Windows на Java — это очень важно и жизненно. Потому что может придти биг босс и сказать что заказчик хочет и платит.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что за нефункциональные требования у тебя там могут быть — не знаю и не хочу обсуждать. Я говорил именно о функциональных требованиях. Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее.
Вообще-то бысрее-ещё-быстрее — это и есть нефункциональные требования. Ну да ладно.
PD>Покажи мне хоть одно место, где я предлагал изничтожить, к примеру, C#. Не найдешь.
Трудно найти хоть одно место, где ты вообще говоришь о C#. Похоже кроме C ты и знать ничего не желаешь. В этом проблема, особенно учитывая, что ты преподаватель.
PD>А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ?
Изолировать от общества? Было дело. В следующий раз специально для тебя буду ставить смайлики, чтобы ты не принимал всё так близко к сердцу.
PD>Так кто из нас терпимее к чужим мнениям ?
IT>>А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории? PD>C#, Java, Fortran, PL/1, VB,, Asm, ну и кое-что по мелочи.
И как, получалось?
IT>>Поможет пересмотр архитектуры. PD>А если ее нельзя пересмотреть ?
Архитектуру можно пересмотреть всегда. Вопрос упирается лишь в целесообразность.
IT>>Купи проц с 16-ю ядрами и сделай алгоритм многопоточным.
PD>Многопоточность тут не поможет, я уже объяснил почему, идет пакетная обработка, так что все равно — одну матрицу разбивать или несколько обрабатывать. А вот насчет 16 ядер — не лукавь. Я тебя спросил — как можно оптимизировать. А ты мне в ответ — купи более мощное железо. Почему бы в таком случае не посоветовать — купи 16 компьютеров ?
Купи 16 компьютеров.
PD>Мой вариант был тогда еще приведен, и в нем ничего не меняется. А вот в твоем время замерь. Без LinQ ты проиграл в 33 раза
Меня это не волнует. Где надо я выиграю, а где не надо у меня приоритеты совсем другие.
IT>>Потому что для решаемой задачи, а именно для файла размером в 120 байт, моё решение будет более чем приемлемым.
PD>А почему же ты тогда, предлагая свое решение (тогда еще, да и сейчас) не оговорился — оно хорошо будет работать для малых файлов, но для достаточно больших его применять не следует ? Если бы ты это сделал — я и возражать бы не стал, если там 120 байт — все равно, что делать. Но ты ведь предлагаешь свое решение как универсальное, не так ли ?
Это решение и для файлов побольше работает не плохо. Но самое забавное, что похожие реальные решения, а не высосанные из пальца, и на больших файлах работают приемлемо. В жизни мне вот никогда не надо было читать последнюю строчку из файла. А весь файл раскладывать на строки приходится периодически.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Например, неправильное форматирование строки в выходном документе — это, конечно, важнее, чем повысить скорость его генерации в 10 раз
Безусловно. И улыбки тут не уместны, чаще всего дело обстоит именно так.
... << RSDN@Home 1.2.0 alpha 4 rev. 1276 on Windows 7 6.1.7600.0>>
Здравствуйте, Pavel Dvorkin, Вы писали:
LVV>>И даже если не устраивает — сначала ошибки убрать, а потом скорость повышать... PD>Например, неправильное форматирование строки в выходном документе — это, конечно, важнее, чем повысить скорость его генерации в 10 раз
Ну да, конечно — компьютер позволяет человеку очень быстро делать ошибки
Ты не описал даже, были ли требования к выходному документу или не были? Может "неправильное форматирование" вообще не является ошибкой?
Если разговор о результатах научных расчетов — то на вид выводных данных, скорее всего, жестких ограничений нет, и на неудачно отформатированные строки можно не обращать внимания. То есть это даже и не ошибка. Просто не очень аккуратный интерфейс. Если же речь о визуальном редакторе — то нахрена он мне нужен, если форматирует текст очень быстро, но неправильно?
Кстати, вполне нормальное решение для редактора, если текст форматируется быстро, правильно, но не очень качественно, т.е. определенная погрешность заложена изначально в алгоритме (как компромисс по быстродействию) и проявления этой погрешности понятны пользователям.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Я никуда не ухожу. Меня интересует прежде всего эффективность всего решения. Если к системе предъявляются серьёзные нефункциональные требования и заказчик за это готов платить, то он это получит, не переживай.
PD>Что за нефункциональные требования у тебя там могут быть — не знаю и не хочу обсуждать. Я говорил именно о функциональных требованиях. Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее.
Быстрее и еще быстрее сделать что? А то может тебе не надо ничего писать а просто скачать Nada — она выполняет свои обязанности в режиме 24/7, с нулевыми затратами процессорного времени и оперативной памяти — просто идеальное решение!
Функциональные требования описывают, что должна делать система. Нефункциональные — как она должна это делать. То есть ограничения, накладываемые при выполнении данных функций. В том числе и ограничения по скорости выполнения заданных функций и потребляемым при этом ресурсам.
Причем, твое ограничение "Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее" делается просто на раз, всегда бы такие задачи мне ставили. Решение очень простое — делаем очень медленную версию, потом немного улучшаем ее — и она "быстрее, черт возьми", потом еще раз улучшаем — и она "Еще быстрее!", а теперь опять оптимизируем — и теперь она "еще быстрее!". Ура, требования по быстродействию удовлетворены всего за 4 релиза, забираем деньги, идем радоваться.
Почему-то чаще ограничения по быстродействию накладываются как-то иначе. Примерно так:
1. Сперва все функциональные требования
2. Нефункциональные:
2.1. Быстродействие:
2.1.1 Имеющееся оборудование (или пределы, какое оборудование возможно установить)
2.1.2 Список по всем функциям системы с указанием максимального (либо, в зависимости от задачи, среднего) времени выполнения данной функции (и, если надо, потребляемых прочих ресурсов) на указанном выше оборудовании.
И что тут характерно — требования четки и легко проверяемые — запускаем программу и смотрим, выполнился ли расчет задачи "А" за 3 секунды или нет (ну и заодно, что посчиталось правильно). Выполнился? Молодцы, вот вам деньги. Нет? Идите дорабатывайте систему.
А вот как доказать заказчику, что ты успешно выполнил функции "Быстрее, черт возьми" и, одновременно, "Еще быстрее"? Особенно, если система — что-то новое и раньше другой версии ее же не было? Тут можно только прогрузить его, что делается это на чистом С и использовалось 148 ассемблерных вставок, и, черт возьми, быстрее уже никто не будет, зуб даю. Короче — упражнение в красноречии.
Жаль у нас таких требований не ставят — у нас есть хороший специалист по маркетингу, уболтает кого угодно. Типа "Вы думаете, что это медленно?! Да вы просто не знаете что такое медленно, а это же очень хорошее решение, что вы, все прекрасно и ровно как вы хотели!"
А вот уболтать спецификацию с явно прописанной цифрой и секундомер, на котором высветилась совсем другая цифра — почему-то выходит с трудом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Re[5]: Павлу Дворкину: о понимании того что делаешь и просты
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, LaptevVV, вы писали:
S>... то надежность будет и так.
LVV>> Надежность "и так" — не будет! Если этим специально не заниматься в процессе разработки... S>А кто говорил, что заниматься никто не будет?
Ты. "Надежность будет и так" понимается (мной) как "не надо ею заниматься". Или объясни, как надо понимать твое высказывание.
IT>Вообще-то бысрее-ещё-быстрее — это и есть нефункциональные требования. Ну да ладно.
Ну-ну... Не сталкивался ты с такими задачами...
PD>>Покажи мне хоть одно место, где я предлагал изничтожить, к примеру, C#. Не найдешь.
IT>Трудно найти хоть одно место, где ты вообще говоришь о C#. Похоже кроме C ты и знать ничего не желаешь. В этом проблема, особенно учитывая, что ты преподаватель.
Неужели ? А мне кажется, что хотя бы одно место ты бы смог без труда найти. Именно то место, где ты так успешно читал строку из файла и где я тебе показал, что из этого получится. Там именно о С# речь и идет.
Ну а если этого мало, то учись пользоваться поиском
407 результатов. Не все, конечно, по существу. И уж конечно, не об особеннстях языка. Впрочем , об особенностях языка ты моих сообщений немного и по С++ найдешь — не люблю я эти дискуссии.
PD>>А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ?
IT>Изолировать от общества?
Нет, там пожестче было.
>Было дело. В следующий раз специально для тебя буду ставить смайлики, чтобы ты не принимал всё так близко к сердцу.
Не поможет. На определенном уровне никаким смайликом не извинишься.
PD>>Так кто из нас терпимее к чужим мнениям ?
IT>
IT>>>А ты сам-то пробовал писать на чём-то другом кроме C? Или это всё теории? PD>>C#, Java, Fortran, PL/1, VB,, Asm, ну и кое-что по мелочи.
IT>И как, получалось?
Представь себе, да. Только все время хотелось поскореее закончить (Fortran и PL/1 исключаю, я с ним работал до С)
IT>Архитектуру можно пересмотреть всегда. Вопрос упирается лишь в целесообразность.
Пересмотри архитектуру сложения матриц, я тебе уже несколько раз предложил это сделать
PD>>Многопоточность тут не поможет, я уже объяснил почему, идет пакетная обработка, так что все равно — одну матрицу разбивать или несколько обрабатывать. А вот насчет 16 ядер — не лукавь. Я тебя спросил — как можно оптимизировать. А ты мне в ответ — купи более мощное железо. Почему бы в таком случае не посоветовать — купи 16 компьютеров ?
IT>Купи 16 компьютеров.
И 16 дополнительных лицензий на 3dparty софт на каждый компьютер, при том, что каждая лицензия в несколько раз дороже компьютера.. Замечательные советы ты даешь. Успехов в их применении!
PD>>Мой вариант был тогда еще приведен, и в нем ничего не меняется. А вот в твоем время замерь. Без LinQ ты проиграл в 33 раза
IT>Меня это не волнует. Где надо я выиграю, а где не надо у меня приоритеты совсем другие.
Тебя не волнует — твое дело, а других — тоже ? Зачем же ты такой совет даешь другим — а вдруг их это волнует ?
IT>Это решение и для файлов побольше работает не плохо. Но самое забавное, что похожие реальные решения, а не высосанные из пальца, и на больших файлах работают приемлемо. В жизни мне вот никогда не надо было читать последнюю строчку из файла.
Так не моя же задача. Ее кто-то там предложил, значит, ему и нужно. А ты свой совет дал.
>А весь файл раскладывать на строки приходится периодически.
Ну я же тебе показал, что твое приемлемое решение в 33 раза медленнеее возможного. Но тебе это все равно. Вот в итоге все и работает в N раз медленнее, чем могло бы.
Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего.
Здравствуйте, AndrewVK, Вы писали:
PD>>Например, неправильное форматирование строки в выходном документе — это, конечно, важнее, чем повысить скорость его генерации в 10 раз
AVK>Безусловно. И улыбки тут не уместны, чаще всего дело обстоит именно так.
М-да. Похоже, если ты это говоришь серьезно, это означает только одно. Мир программирования разошелся на разные квартиры уже настолько, что представителям разных кваритр не легче понять друг друга чем алеуту папуаса.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>М-да. Похоже, если ты это говоришь серьезно, это означает только одно. Мир программирования разошелся на разные квартиры уже настолько, что представителям разных кваритр не легче понять друг друга чем алеуту папуаса.
Я говорю это серьезно. И, Павел, тебе об этом давно говорят — твои задачи весьма узкие, не стоит обобщать на всех.
... << RSDN@Home 1.2.0 alpha 4 rev. 1284 on Windows 7 6.1.7600.0>>
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, Pavel Dvorkin, Вы писали:
F>Быстрее и еще быстрее сделать что? А то может тебе не надо ничего писать а просто скачать Nada — она выполняет свои обязанности в режиме 24/7, с нулевыми затратами процессорного времени и оперативной памяти — просто идеальное решение!
Смотреть лень. Если можешь, расскажи, как там хотя бы суммировать матрицы 5000*5000 с нулевыми затратами процессорного времени.
F>Функциональные требования описывают, что должна делать система.
+1
>Нефункциональные — как она должна это делать. То есть ограничения, накладываемые при выполнении данных функций.
Эти ограничения тоже функциональны. Например, требование решать некую NP-полную задачу — это функциональное ? А если это требуют делать при N=1000, это уже нефункционально ? Сначала напишешь алгоритм полного перебора, а потом скажешь — ой, извините, ответ вы получите в 50 веке
>В том числе и ограничения по скорости выполнения заданных функций и потребляемым при этом ресурсам.
Дело в том. что решение, которое не укладывается в некий минимум по времени, в моих задачах не есть решение вообще. Он просто неприемлемо изначально, его никто и обсуждать не будет.
F>Причем, твое ограничение "Быстрее, черт возьми. Еще быстрее! А теперь еще быстрее" делается просто на раз, всегда бы такие задачи мне ставили. Решение очень простое — делаем очень медленную версию, потом немного улучшаем ее — и она "быстрее, черт возьми", потом еще раз улучшаем — и она "Еще быстрее!", а теперь опять оптимизируем — и теперь она "еще быстрее!". Ура, требования по быстродействию удовлетворены всего за 4 релиза, забираем деньги, идем радоваться.
Не спеши радоваться. Дело в том, что после того, как ты сделаешь очень медленную версию, тебя просто уволят. Она просто никому не нужна.
F>Почему-то чаще ограничения по быстродействию накладываются как-то иначе. Примерно так:
F>1. Сперва все функциональные требования F>2. Нефункциональные: F>2.1. Быстродействие:
Еще раз. Быстродействие входит в число функциональных требований. При недостаточно высоком — решение просто не рассматривается.
Вот представь себе ПО управления самолетом. Если оно будет реагировать на изменение обстановки очень медленно — его просто выкинут сразу. В функциональные требования такого ПО входит — реакция не медленнее, чем за такое-то время. Более того. Если окажется, что удовлетворить другим требованиям за это время не удастся — я вполне могу допустить, что часть других требований будет снята или ослаблена. А время — нет, потому что если реакция будет медленнее, чем ..., то управлять уже будет нечем.
У меня, конечно, не самолетное ПО, но идея та же самая. Риски там, правда, нулевые, ничего не грохнется, но недостаточно быстрые решения не рассматриваются. А для достаточно быстрого решения всегда макисма такая — сделайте еще быстрее, если можете.
F>А вот как доказать заказчику, что ты успешно выполнил функции "Быстрее, черт возьми" и, одновременно, "Еще быстрее"? Особенно, если система — что-то новое и раньше другой версии ее же не было? Тут можно только прогрузить его, что делается это на чистом С и использовалось 148 ассемблерных вставок, и, черт возьми, быстрее уже никто не будет, зуб даю. Короче — упражнение в красноречии.
Если нет совсем аналогов — может, и да. Но аналоги обычно есть. И если заказчик мне показывает коммареческую программу, которая делает это за 3 сек, а я ему сначала делаю за 500 мсек, а потом на CUDA за 100 — он будет (был) доволен, хотя не исключено, что попросит сделать за 50 мсек. А поскольку он меня давно знает и знает, что я делаю максимум из того. что могу, то дальше будет одно из двух — либо я сделаю за 50 мсек, либо заяввлю — все, предел, лучше не могу. Он мне поверит, не волнуйся . Впрочем, поверит и в случае, если ПО нне имеет аналогов.
F>А вот уболтать спецификацию с явно прописанной цифрой и секундомер, на котором высветилась совсем другая цифра — почему-то выходит с трудом.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>М-да. Похоже, если ты это говоришь серьезно, это означает только одно. Мир программирования разошелся на разные квартиры уже настолько, что представителям разных кваритр не легче понять друг друга чем алеуту папуаса.
AVK>Я говорю это серьезно. И, Павел, тебе об этом давно говорят — твои задачи весьма узкие, не стоит обобщать на всех.
Да и не обобщаю я. Я просто говорю — бывает и иначе.
Ну а насчет узких и широких задач — тут надо статистику приводить.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Вообще-то бысрее-ещё-быстрее — это и есть нефункциональные требования. Ну да ладно. PD>Ну-ну... Не сталкивался ты с такими задачами...
Откуда тебе знать с какими задачами я сталкивался? Или у тебя начинает появлятся синдром первого парня на деревне, и ты думаешь, что ты один занимаешься чем-то уникальным и высокотехнологичным?
PD>>>А вот что ты предлагал делать с теми, кто на С++ программирует, я не забыл. Напомнить ? IT>>Изолировать от общества? PD>Нет, там пожестче было.
Изолировать-изолировать от общества?
>>Было дело. В следующий раз специально для тебя буду ставить смайлики, чтобы ты не принимал всё так близко к сердцу. PD>Не поможет. На определенном уровне никаким смайликом не извинишься.
Да уж.
IT>>И как, получалось? PD>Представь себе, да. Только все время хотелось поскореее закончить (Fortran и PL/1 исключаю, я с ним работал до С)
Жаль, ты не застал программирование на тумблерах, наверняка ты по этому скучал бы больше всего.
IT>>Архитектуру можно пересмотреть всегда. Вопрос упирается лишь в целесообразность. PD>Пересмотри архитектуру сложения матриц, я тебе уже несколько раз предложил это сделать
Пересматривать нужно архитектуру решаемой задачи в целом, а не твоего частного решения. Тебе, кстати, об этом постоянно напоминают, когда ты пытаешься предложить улучшить какой-нибудь код на C. Устранять нужно причину, а не последствия.
IT>>Купи 16 компьютеров. PD>И 16 дополнительных лицензий на 3dparty софт на каждый компьютер, при том, что каждая лицензия в несколько раз дороже компьютера.. Замечательные советы ты даешь. Успехов в их применении!
Тогда купи один компьютер с 16-ю ядрами.
IT>>Это решение и для файлов побольше работает не плохо. Но самое забавное, что похожие реальные решения, а не высосанные из пальца, и на больших файлах работают приемлемо. В жизни мне вот никогда не надо было читать последнюю строчку из файла.
PD>Так не моя же задача. Ее кто-то там предложил, значит, ему и нужно. А ты свой совет дал.
И что плохого в моём совете? То, что я могу свой код даже ночью спросонья без проблем воспроизвести за 10 секунд. Вот ты можешь своё решение воспроизвести за 10 секунд? А я могу.
PD>Ну я же тебе показал, что твое приемлемое решение в 33 раза медленнеее возможного. Но тебе это все равно. Вот в итоге все и работает в N раз медленнее, чем могло бы.
Я тебе в 33-й раз повторяю. Моё решение в большинстве случаев работает со вполне приемлемой скоростью. Если оно будет работать даже на 3 порядка быстрее, то этого всё равно никто не заметит. А насчёт "вот в итоге все и работает" — это твои домыслы. Там где надо мой код работает быстро, очень быстро, ещё быстрее и оптимизациям уделяется достаточно внимания. Но растрачивать свою жизнь на оптимизации всего и вся просто глупо.
PD>Ну а если говорить о разложении файла на строчки — зачем ? Он и так разложен, своей структурой. Остается только отмэппить его в память, сделать массив указателей на строчки, и все. Ни один байт исходного текста ни копировать, ни двигать не надо. Вообще не надо. Ничего.
Ну да, только не забудь переводы строк нулями забить в своём файле.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
