Здравствуйте, GlebZ, Вы писали:

GZ>Да уж. Я тогда маленький был. Слышал о монстрах которые для того чтобы понять программу переписывали с ассемблера на коды.

Нет. Они просто ее писали в кодах, с самого начала

>Таже NT4 — с последними сервис паками мег 100 занимает оперативы.

У нас еще старый класс есть, для первокурсников, там 64 Мб и NT4. Вполне работает, SP последний.

GZ>Я бы не стал так говорить. Можно просто программы классифицировать:
GZ>1. Резидентные программы на машинах пользователей. Они действительно должны быть компактными, не должны забирать много ресурсов компа, и не мешать пользователю выполнять его основную работу.

+

GZ>2. Резидентные серверные программы. Строго наоборот. Они должны адаптировать полностью ресурсы компьютера ради своей эффективности. И никак иначе.

+-. И да, и нет. Потму как этих серверных программ на машине может быть несколько, и лучше бы им не брать все ресурсы компьютера, а то придется по серверу на каждую программу иметь.

GZ>3. Пользовательские программы. Наверно этот класс программ ты и имел ввиду. Вот именно это и есть путь для компромиса. И компромисс между функциональностью и ресурсами. Если функциональность нужная, и она требует достаточно ресурсов, то пользователь не будет возражать, по опыту знаю. Если в требованиях к программе не записано что попутно должны генерится сцены 3D Studio Max, то ему несложно будет выгрузить ее, или понять о том, что это была именно его ошибка. Но вот если функциональность ненужная, а требует достаточно ресурсов, то здесь и я сильно возмущаюсь(а такое на каждом шагу ). Но существует еще вопрос, что значит избыточность ресурсов? Если моя программа занимает на N мегабайт больше, и при этом я уверен что количество ошибок(которые есть будут и полностью их поубивать нельзя) значительно меньше, то я займу эти N мегабайт. В принципе, это и есть некоторая цель Net Framework.

Если я напишу это же без FrameWork, алгоритм будет тот же, эффективность выше и памяти меньше, то это будет лучше. А то, что на FrameWork ошибок будет меньше — не уверен. Не все сводится к мемори ликам и некорректным индексам. От ошибок алгоритма меня никакой FrameWork не защащает. Складывать килограммы с метрами (вместо того, чтобы умножать) и там вполне можно, .


>Пользовательские компьютеры сейчас избыточны. У них значительно больше памяти чем нужно, и процессоры значительно быстрее чем нужно для большинство задач.

Я бы эту фразу перевернул.
Большинство программ таково, что они используют значительно больше памяти и процессорного времени, чем им в действительности нужно. Поэтому программ, которые могли бы при оптимальной эффективности использовать память и процессор, не существует (почти), так как при нынешнем стиле написания программ им нужны намного большие ресурсы, которых пока нет.


GZ>Все это ресурсы избыточны для повседневной работы. Мне не жалко 20 мегабайт — если у меня их 500.

Во-во. Тебе надо 20, а берешь 40. Мне надо 50 — беру 80. Ему надо 100 — берет 150. А этому надо еще 100 — пошел вон, памяти больше нет.

>Если у меня есть вариант, что адаптировав эту избыточность я повышену эффективность даже не программы. а разработки, я ею воспользуюсь.

Да, увы, это так. Ты сделаешь быстрее, не спорю. И сэкономишь несколько К$ на своей зарплате. А в итоге 100,000 пользователей потратят несколько сотен тысяч $ на память, которую твоя программа заняла и не использует.

GZ>Для данной конкретной задачи, это корректное замечание. Net — не очень подходит под числодробилки.

Да ведь нам говорят, что .Net — генеральная линия развития, а те, кому она не нравится — неандертальцы. Вот и мне сегодня заказчик сообщил, что планирует нечто на .Net. Пока не знаю что. И не убедишь его, что это , м.б. не лучшее решение.



GZ>>>Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест.

"У нас никогда нет времени на то, чтобы сделать все как следует, но всегда есть время на переделки"

>А также оптимизацией памяти, если ее оказалось недостаточно.

Ничего ты не соптимизиуешь. Не ты лично, а те, кто к эффективности не привык. Им и в голову не придет, что это все на 20 Мб может меньше требовать.

GZ>1. Если ты получил понятную программу, достаточно маленьку по исходным кодам, которую прочитает любой ребенок, и которая представляет вверх искуства программирования на ООП, это совсем не значит что она есть эффективна в плане использования памяти и процессора. Даже сказал бы наоборот. Но вот то, что в ней ошибки локализованы, сопровождать ее легко — это факт. После этого ее доводят до требуемого уровня производительности. Это делается легко, поскольку дизайн программы легко сопровождаем.

Ну и заявление! Дизайн понятен, сопровождение легко, след-но, оптимизировать будет несложно! А то, что для оптимального решения задачи, возможно, надо не в деталях оптимизировать, а все решение пересмотреть и весь дизайн переделать — это ты не допускаешь ? Совсем другим способом ее решать!


GZ>Во — вторых, ты увеличиваешь сложность дизайна тогда когда он наиболее важен. В результате, при добавлении функциональности увеличивается количество ошибок. IMHO Это более тяжко чем неэффективное использование ресурсов.

ИМХО это лечится рано или поздно, а первое — не всегда.

GZ>Вобщем, мое мнение, что оптимизация программ по используемым ресурсам, должны проходить в 3 плоскостях:
GZ>1. При построении архитектуры. Мы еще видим все проблемы в комплексе, и наиболее крупные можем сразу решить.

+


GZ>2. Алгоритмическая оптимизация. Неэффективный алгоритм на порядки хуже неоптимизированного кода.

+++

GZ>3. Оптимизация готового продукта под конкретные требования пользователя. Свое мнение я уже описал.

+-

GZ>Пользуйся альтернативами Я понимаю что в случае крупных монополистов — такое плохо проходит. Слишком высока сложность программ. Но нельзя так говорить о всей отрасли. Пользуются же мирандой вместо аськи.

Да, а вместо Net Framework что предложишь ? Вместо MS Office ?




PD>>Если я это сделаю, и все же уложусь в мег, ты меня все равно выгонишь ? Если я вместо буфера в несколько мег, в котроый все читается, использую MMF, в котором доступ будет только к тому, что реально требуется — тоже выгонишь ?
GZ>Да. Я вполне представляю весь процесс сооружения такой программы. Если ты потратил время на то, чтобы адаптировать решение на меньшие ресурсы, когда я знаю что ресурсы заказчика(или предполагаемого заказчика) значительно больше, то безусловно. Ты проделал работу, которая никому не нужна. Мало того, ты усложнил сопровождение программы. Для программ класса серверов приложений — я не вижу исключений из этого правила.

Опять -таки — все верно, если у тебя единственный заказчик. Ему хоть на 2Gb пиши, если у него их 4. Но я-то о других случаях говорю.



GZ>С уважением, Gleb.