Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно. Ну
что же — к счастью, я уже не в том возрасте, когда падение или рост рейтинга
могут серьезно повлиять на самочувствие.

Итак...

Когда компьютеры были большими, память у них была маленькой и
быстродействие тоже. И поэтому гуру от этих ЭВМ ничего, кроме ассемблера
(автокода, по-тогдашнему) и не признавали. А на нас, всяких там алгольщиков или
фортранщиков, смотрели свысока — писать , мол, эффективные программы не умеют,
только зря машинное время расходуют. Мы, конечно, с ними на словах не
соглашались и всякие аргументы приводили, но в глубине души их правоту, пожалуй,
признавали.
И действительно, как было не признать! Пока программа небольшая и в память
помещается — ладно, живите и радуйтесь! Ну а как побольше стала ? Тут-то и
придется признать свое бессилие. А гуру, им что, всегда что-нибудь придумают.
Кто-нибудь из нынешнего поколения слышал про "самоубийство программ" ? Нет, это
не стирание EXE-файла во время его работы. Это когда программа во время своей
работы использует память, занятую своими командами (которые уже отработали и
больше не потребуются) под свои данные. Вряд ли кому-нибудь придется этим сейчас
заниматься, и слава богу. А вот когда у Вас всего 18 Кбайт, то и таким не
пренебрегали.
Потом компьютеры стали больше. И в размерах (один мой знакомый, рост у
него 1.80, любит рассказывать, как он в процессор некоторой машины входил не
наклоняясь , но все же и память с быстродействием тоже росли. Вспоминаю
сейчас ЕС-1022. Памяти там было уже 512 Кбайт, правда, сотню из них занимала ОС.
Остальные 400 делились между 3-4 одновременно работавшими программами разных
пользователей. Так что на тех, кто заказывал больше 200 Кбайт, на ВЦ смотрели
довольно косо — за наш счет ведь! И правильно смотрели — нечего тут жировать!
Компилятор с Фортрана на 96 КБайтах работал, c PL/1 — даже на 64 Кбайтах (до сих
пор не знаю, почему — PL/1 сложнее Фортрана), линкеру тоже 96 Кбайт хватало, а
тебе так 200 надо ? Иди-ка, батенька, да перепиши свою программу как следует. До
сих пор помню, как потратил несколько часов, пытаясь написать вычисление
произведения трех матриц без промежуточной матрицы (было это на заре моей
карьеры, а я ведь химик .И студента своего, который без надобности
транспонировал матрицу, заведя еще одну, так отругал, что он долго это помнил :-
)
В общем, если говорить серьезнее, эффективность у нас была всегда на
первом плане. Не как-нибудь написать, а наиболее эффективным способом,
не любой алгоритм использовать, а лучший для этого случая. На этом мы
прочно стояли.
Поймите меня правильно. Это вовсе не значит, что мы оптимизировали
все и вся. Код, который работает 0.1 сек и занимает 100 байт, никто
не оптимизировал. И то, что оптимизировать нужно самые внутренние
циклы, мы прекрасно знали. Не об этом речь. А о том, что при написании
программ была определенная культура, требовавшая памятью не сорить
без надобности, первый попавшийся алгоритм не применять, а искать хороший,
ну и т.д.
Потом компьютеры стали меньше. И по размерам, и по быстродействию и
памяти тоже. Не потому, что большие исчезли, а потому, что малые
появились. Их так и называли — мини-ЭВМ. СМ-4, к примеру. Памяти у нее
было поменьше, быстродействие похуже, чем у той же ЕС-1022, зато у нее
было неоспоримое преимущество — она была моя! Никакого тебе ВЦ с десятком
конкурентов, никаких "Правил работы на ВЦ ... института", правила такие,
какие я хочу. Все это не могло не радовать, но все же уменьшение
памяти и быстродействия огорчало и тем более заставляло бороться
за эффективность. Первая моя серьезная работа на СМ-4 — адаптировать к
ней программу, которая на ЕС занимала 220 Кбайт, а здесь их всего 256.
Когда я понял, как ее в свободные 200 уложить — выяснилось, что понял
я неправильно, и для кода я могу рассчитывать только на 64 Кбайта, а
остальную память только под данные можно использовать. Вот тут-то я
и покрутился. Вы никогда не делали оверлейные структуры 9-го уровня ?
Даже не знаете, что это такое ? Ну и прекрасно, и не надо вам знать
Потом машины стали совсем маленькими, а быстродействие и память
уменьшились до неприличия. Проще говоря, пересел я на Ямаху-1. Память 64 Кбайта,
частота 2MHz, флоппи-диск — живи и радуйся! В общем, 8-битная машина. И вот на
этой машине я увидел чудо.
Чудо называлось Turbo Pascal 1.0. Сказать, что он меня поразил — не то
слово. И не меня только. Все, кто до этого Ямаху не видел (а их в Омск
очень немного попало тогда) и кому я о нем говорил, отвечали мне одинаково-
такого не может быть!
В 64 Кбайтах размещались
MSX-DOS, точнее , ее резидентная часть — несколько Кбайт
сам компилятор Turbo Pascal. Сидел резидентно в памяти.
редактор текста Turbo Pascal, вполне приличный по тому времени.
исходный текст программы, набранный в этом редакторе.
рабочая программа (машинные команды). Да-да, я не оговорился.В обычном
режиме компиляции программа размещалась в ОП и на диск не записывалась. И
не думайте, что это какой-то паршивый интерпретатор был, нет, самый
настоящий компилятор. Чуть позже (я уже в университете работал) был
у нас класс "Ямаха-2", память там была уже 128 Кбайт, а дисков на рабочих
станциях не было. Так вот. половину из этих 128 Кбайт мы отводили
под электронный диск, туда в начале занятия записывали Turbo Pascal,
а в конце с него переписывали на машину преподавателя .pas файлы студента.
Остановимся на минуту и вдумаемся. Итак, все это помещалось в 64 Кбайта.
Можно было, значит, написать это так, чтобы помещалось. Если, конечно,
эффективно написать. И работало это с вполне по тем временам приличной
скоростью. Не хуже, чем на СМ-4, кстати сказать. Даже лучше.
А потом компьютеры, хоть и не меньше и не больше по размерам стали, начали
резко увеличивать свою память и быстродействие. Сейчас любят вспоминать
пророчество Б.Гейтса — дескать, 256 Кбайт всем хватит. Ну, во-первых,
не думаю, что они имел в виду, что это навсегда. Во-вторых, никто,
в т.ч. Гейтс, в то время не понимал, что на свет явился не расширенный
калькулятор для научных лабораторий, а нечто такое, что перевернет
мир. А 256 Кбайт по тем временам — очень даже много. Настолько много,
что для большинства тогдашних задач это даже и не требовалось. Впрочем,
довольно скоро от этих 256 к 640 перебрались, на этом значении, правда,
надолго застряли.
Вот тут первые шаги в сторону пренебрежения оптимальностью уже и начались.
Действительно, на машине 600 Кбайт свободно, машина однопрограммная,
конкурентов нет, зачем мне пытаться программу в 100 Кбайт уложить ,если можно
все 500 спокойно использовать. Впрочем, память памятью, а есть еще и
быстродействие. Оно было еще очень маленьким, так что хотя бы в этом
плане писать все же приходилось эффективно, выжимать из машины все, что можно.
Так что писать старались все же эффективно, хотя десятком, а то и сотней
лишних Кбайт уже не мелочились.
Что было дальше — все знают. Память и быстродействие росли, эффективность
падала так же быстро, как те росли. Выяснилось, что и 1 Мбайта мало для
программы, предыдущая версия которой вполне 256 К было достаточно, да что там
1Мбайта, и 2 мало, и 16 мало, подайте 32, нет, 32 тоже мало, без 64 не
обойдемся.
Вот вам 2 классических примера.
Конечно, Object Pascal не Turbo Pascal, а Delphi 7 не Turbo Pascal 1.0.
Но, положа руку на сердце — неужели язык в 1000 раз усложнился ? Ну в 5-10
раз сложнее стал, не спорю (я имею в виду в плане написания собственно
компилятора, а не IDE, отладчика и т.д.). А раз так, то для компиляции
консольных приложений компилятор командной строки-то уж должен в 640 Кбайт
уложиться ? Дудки вам, а не 640 Кбайт. В 640 Кбайт сейчас умеют только "Hello,
World" укладывать! Пока несколько десятков Мбайт не будет, и не подходите.
Другой пример — сама Windows. Я прекрасно понимаю, что Windows NT 4 и
Windows XP — не совсем одно и то же. Но та на 8 Мбайтах работала, а эта от
128 нос воротит, подавай ей 256. А ядро, вообще говоря, претерпело не такие
уж большие изменения.
Почему же так произошло? На мой взгляд, просто потому, что требованию
эффективности просто перестали уделять нужное внимание. Если памяти много —
чего ее жалеть, зачем экономить? Какой смысл бороться за то, чтобы твоя
программа занимала 8 Мбайт, если можно взять 64 ? Даже, пожалуй, наоборот-
увидят, что твоя программа меньше памяти занимает, чем у конкурента — ну
и решат, что та более крутая
Разумеется, эффективности внимание перестали уделять не везде. Для тех
программ, которые и сейчас работают на пределе возможностей машины, за
эффективность по-прежнему борются, да еще как, иначе ведь работать вообще
не будет. Ну а там, где для предела далеко — чего это мы будем лишний
десяток Мбайт экономить ? Пусть пользователь память докупит, она нынче
дешевая!
Вспоминаю один случай из своей практики. Вел я тогда кружок в средней
школе,хорошие ребята попались, большинство из них потом наш матфак закончили. В
DOS на Turbo Pascal, лет 10 назад это было. И вот дал я одниу мальчику
упражнение, сделал он его, показал мне, посмотрел я , похвалил и добавил :"А
теперь, Илья, выкинь отсюда этот массив. Он здесь совсем не нужен, и без него
даже лучше получится". До сих пор помню тот взгляд, которым он меня одарил
Если кто-то думает, что моей целью было 200 байт сэкономить — ничего Вы
из моих рассуждений не поняли. Моей целью было научить его грамотно писать
программы, делать как следует, а не так, как получится. Не реализовать первую
пришедшую в голову идею, а подумать, нельзя ли здесь лучше сделать! Потому что
если я сейчас это пропущу — он и дальше будет так же делать, тройные циклы
писать там, где двойных хватит и лишние массивы без надобности заводить.
Меня тут некоторые уже обвиняли в "наездах" на C# и .Net. Вообще-то
я такое понятие "наезд" — не признаю. Если к любимой системе программирования,
компилятору и т.д. подходить с позиций "В России нет еще пока команды лучше
Спартака" — тогда, конечно, всякая критика левого крайнего Спартака есть явный
наезд . Если же подходить к этому вопросу объективно, скажем, с позиций
человека, который вообще ни за одну команду не болеет или болеет за Реал-Мадрид,
то сравнение левого крайнего Спартака и левого крайнего ЦСКА есть дело вполне
разумное, и если вывод будет не в пользу спартаковца — ничего страшного тут нет,
что же поделаешь... Другого левого крайнего искать надо, а может, стоит из
ЦСКА его переманить .
Так что в том. что примеры я буду приводить именно из области .Net — не
есть наезд на нее. Просто ИМХО она наиболее ярким образом характеризует то, о
чем я пишу.
Вот простой пример. Ставя свои эксперименты, обнаружил я , что в
библиотеке .Net не имеется способа получить список файлов каталога без того,
чтобы не прочитать его полностью.

http://www.rsdn.ru/Forum/Message.aspx?mid=1398903&only=1

Автор: Pavel Dvorkin
Дата: 23.09.05

Чтобы не было неясностей — класс DirectoryInfo как он есть, не позволяет.
То, что можно самому написать, с использованием InterOp — я это и до
постинга вполне понимал.
Мне это показалось странным, и я решил вопрос в форуме задать. В общем,
объяснили мне то, что я и так знал, и подтвердили , что без InterOp это
не делается, а с ним — великолепно.

Поясню, в чем проблема здесь. С помощью Win32 функций можно записи
о файлах по одной получать. Времени на чтение всего каталога это
никак не уменьшит, это вообще не от моей программы, а от драйвера
ФС зависит, а вот памяти мне в Win32 почти совсем не надо — одна
структура WIN32_FIND_DATA на все файлы, хоть 100 их будет, хоть
миллион. А класс DirectoryInfo предлагает считать весь каталог
в оперативную память (массив FileInfo), а потом уж из него брать.

Проверил я этот DirectoryInfo на имеющемся у меня каталоге в
100,000 файлов. Работало это все 1 минуту (неудивительно, и Win32 программа
не меньше бы потребовала, FAR, к примеру, именно столько и требует)
и заняло по Task Manager 57 Мбайт.

Ну ладно, я не вчера родился, и как это на Win32 делается — еще лет 10
назад знал Так что такое решение, приведись мне это в реальной программе
писать, меня вряд ли бы устроило, и что-нибудь бы придумал или вопрос бы задал.
А как же будут делать те, кто школу более или менее эффективного (в этом
плане, только в этом плане!) программирования в Win32 не прошел, а сразу за .Net
взялся ?
Вот ведь что мне Sinclair советует

http://www.rsdn.ru/Forum/Message.aspx?mid=1404835&only=1

Автор: Sinclair
Дата: 27.09.05

Цитирую

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

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

http://www.rsdn.ru/Forum/Message.aspx?mid=1403668&only=1

Автор: VladD2
Дата: 27.09.05

>А производительность и не должна быть на первом месте. Она должна быть
достаточной. А на первом месте должны быть удобство и простота.

Я не против удобства и простоты. Я за. А вот что такое "достаточной" —
извольте объяснить. Если машина однопрограммная — тогда, конечно, достаточно —
если помещается в память и достаточно быстро работает. А в многопрограммной
коммунальной квартире стоит еще и о других подумать. Потому как память хоть и
большая, но не резиновая. И процессор пока что только один, как правило.

Или вот другой пример — с умножением матриц

http://www.rsdn.ru/Forum/Message.aspx?mid=1410674&only=1

Автор: Pavel Dvorkin
Дата: 30.09.05

Я не касаюсь сейчас вопроса, можно ли это было оптимизировать. В дискуссии на
эту тему

http://www.rsdn.ru/Forum/Message.aspx?mid=1408480&only=1

Автор: Pavel Dvorkin
Дата: 29.09.05

был предложен не один способ это сделать, да я и сам предложил с самого начала
свой — как ни плохо .Net я знаю, а все же догадаться несложно было. Мой вопрос в
другом — кто именно этот вариант алгоритма так реализовал, что он вместо
чего-то похожего на n^3 показывает временную зависимость, напоминающую утренние
прыжки моего кота, когда он есть просит ? . Чтобы с увеличением размера
матрицы на 100 время уменьшалось, а при увеличении еще на 200 — увеличивалось в
10 раз —
такого в моей практике еще не было! Не знаю, кто тут виноват, не знаю, кто
эту исполняющую систему писал, но об эффективности здесь говорить не приходится.

Другой пример на эту же тему. Клонирование объектов (deep copy). Рихтер
для этого советует простой способ — сериализовать в memory stream, а потом
десериализовать. Просто ? Да. Изящно ? Да. Только при этом как-то забывают,
что вместо одной операции копирования мы здесь имеем две, и вместо двух
наборов байт (source и destination) имеем три — source, intermediate и
destination.
Правда, Рихтер тут же отмечает, что эта операция может оказаться слишком
дорогой,да и не всегда возможной. Рихтер, безусловно, понимает, когда ее можно
применять, а когда не стоит. Понимают ли это все разработчики под .Net ? Боюсь,
что нет. Так что будут они этот способ использовать, не слишком задумываясь,
скорее всего. Сериализуют двумерную матрицу размером в несколько Мбайт, и все
дела

Кстати, и о самой сериализации. Нет слов — реализовано в .Net красиво. Помечаешь
атрибутом, и все! Только вот не стоит забывать, что бесплатный сэр бывает только
в мышеловках. Конечно, приятно, что за тебя все сделают — reflection, чтение
значений, запись, проход по все ссылкам и опять reflection, чтение значений,
запись. А между тем грамотно написанный код в той же MFC, использующий
сериализацию, сделает в принципе то же самое без того, чтобы изучать
структуру класса(ов) и тратить на это время и память.


В в результате такого отношения — "что нам десяток Мбайт жалеть, что
нам с того, что это здесь на 100 мсек дольше выполняться будет", получается то,
о чем хорошо сказал Cyberax

http://www.rsdn.ru/Forum/Message.aspx?mid=1409923&only=1

Автор: Cyberax
Дата: 29.09.05

>Чего-то я начинаю в этой истине сомневаться. Слишком часто все "не
тормозит" (или не жрет памяти) в отдельности, но работает со скоростью
улитки (или жрет гигибайты) в целом.

>Причем наблюдается это, в основном, у современного софта — та же ICQ без
зазрения совести сжирает 20 метров памяти. Какой-нибудь WinAmp еще 20
метров. Вот так и не остается памяти для чего-нибудь полезного....

Хороший, кстати, пример — ICQ. Написана она не на .Net ИМХО (давно
ее не держу, у меня Trillian, ему 7.5 Мбайт хватает . По существу — текстовый редактор плюс модуль связи с winsock. Все остальные возможности его используются
один раз в неделю, если не в месяц. Я ничего против них не имею, но
сидели бы они на диске в виде DLL и раз в неделю загружались! Так нет,
20 Мб вынь да положь! Интересно, под что?
Если бы ICQ был в DOS времена (кстати, был?), то быть бы ему
там TSR размером в 30-40 Кбайт максимум, и писать в нем свои SMS можно было
бы так же, или почти так же, как сейчас, разве что в текстовом
режиме. Да, ладно, бог с ней. с DOS. Сколько места занимали первые
версии ICQ (жаль, не сохранил я тот клиент, с которым начинал лет
8 назад), и сколько сейчас? Памяти много, чего ее жалеть!

Мне тут VladD2 упрек такой кинул — дескать, писать надо , не
слишком думая об эффективности, а потом узкие места можно оптимизировать.
Теоретически — совершенно безупречное рассуждение. А практически — это
верно, если Вы заранее какой-то целью задаетесь — по памяти не более...
или по времени не медленнее ... Если нет — никто и не будет оптимизировать,
потому как совершенно непонятно, что и зачем. Работает каждый модуль раз в
5 дольше , чем можно было бы, памяти кушает раз в 5 больше, чем надо было
бы — что тут оптимизировать? Так и должно быть, все нормально сделали!

В результате получаем некую самодвижущуюся повозку размером с аэроплан,
ставим на нее ракетный двигатель, запускаем — едет! Едет ведь! Со скоростью
60 км/час. Ну вот это и есть настоящий аэроплан, в серию его и пусть
по дорогам ездит. А когда этим разработчикам объясняешь, что аэроплан
должен не ездить, а летать, и не 60, а 900 км/ч давать, а если Вы автомобиль
делали, то он и при двигателе внутреннего сгорания должен эти 60 (а то и 120)
давать, да и размерами должен быть раз в 20 меньше — удивляются, чего, мол,
привязался! Ездят же на нем, чего тебе надо!

А теперь перехожу к главному, что меня беспокоит.

Создается впечатление, что рост быстродействия процессоров несколько
замедлился. Может быть, я не прав, но мне кажется, что мы подошли к некоторому
пределу, и если не последует технологического прорыва, то скорость сильно расти
не будет. Еще раз — может быть, я не прав. Кстати, о памяти пока в этом плане
говорить не приходится.

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

И вот тогда этот неэффективный стиль программирования даст себя знать!
Сейчас можно просто рассуждать — чего я буду 20 Мбайт экономить, если
пользователь без проблем 256 может докупить ? А вот когда опять в жестких
лимитах работать придется — окажется, что некоторые программы, которые вполне
могли бы быть написаны, написаны не будут, или же будут написаны лет через 10
после того момента, когда они могли бы появиться! Потому что эффективно
работать большинство не умеет. Привычки у них такие — что нам стоит лишних
десяток Мбайт взять!

Не согласны ? OK, кто из вас взялся бы написать "Turbo Pascal 1.0"
образца 2005 года? Который будет работать в такой маленькой памяти — 512 Мбайт
и на таком медленном процессоре с частотой всего 3 GHz ? Боюсь, что Вы
потребуете для этого 16 Gb памяти и не менее 30 GHz . Вы же прекрасно знаете,
какие ресурсы для чего требуются, поэтому оцените их для этой задачи и получите
16 Gb и 30 GHz, А где их взять? Впрочем, нет, не потребуете. Вы даже задачу
такую не поставите — Вам она и в голову не придет: Боюсь, что мы даже и не
узнаем, что могло бы быть написанным, если бы это эффективно делалось...

Ну и к чему автор призывает, спросите Вы ? К поголовному возврату на
ассемблер
и к 64 Кбайтам ? К отказу от того пути, по которому сейчас пошло развитие ?

Я не настолько наивен, чтобы к этому призывать. Просто одно скажу :

Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
это возможно!

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

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
PD>это возможно!

Все зависит от задач, от времени и еще кучи других факторов.
Где-то можно легко пожертвовать эффективностью.
Где-то не получится.
Вот у нас пишут систему на PC и для железяки со считанными килобайтами.
Угадай где мы жестко оптимизируем, а где в очень редких случаях.

В общем призыв "оптимизируйте везде" так же далек от жизни,
как и призыв "забейте на оптимизации и просто докупите память".

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

<...>

Подписываюсь под всем, почти.

Просто, как говорится, кто девушку обедает — тот ее и танцует. И в разработке ПО, бог — заказчик. А ему, насколько я знаю, зачастую не нужно наилучшее решение, ему нужно, чтобы быстро, более-менее качественно, документированно, сопровождаемо...

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

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
PD>это возможно!

Имхо, пока за скорость разработки платят больше, чем за скорость работы заказанной программы, этот призыв останется "гласом вопиющего в пустыне".

E>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
PD>>это возможно!

E>Имхо, пока за скорость разработки платят больше, чем за скорость работы заказанной программы, этот призыв останется "гласом вопиющего в пустыне".

Спасибо автору топика, за то, что вернул ко временам моей программисткой юности Присоединяюсь.
В качестве продолжения посмотрите, коллеги, вот эту статью одного ассемблерщика http://www.wasm.ru/article.php?article=onebyte. Не перевелись еще богатыри

PS: про ICQ подмечено очень верно. у меня на телефоне Siemens M55 (далеко не смартфон) MobICQ работает, и еще как...

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

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
PD>это возможно!

Архивредный совет дал нам уважаемый тов.Павел Дворкин!
Несвоевременный!
Какой же несвоевременный совет!

Наоборот, пусть неэффективность плодится и размножается, путь цветет и пахнет. Пусть сотни тысячи индусов копипастят миллионы строчек на managed языках. Пусть фреймворки становятся все толще и прожорливее. Путь рядовой пользователь меняет свой ПК не каждые два года, а каждые полгода. А корпоративные заказчики удваивают мощности своих серверов и класстеров после каждого выпущенного нами сервис-пака. Пусть XML процветает в телекоммуникационных протоколах -- долой всякие ASN1 и прочие двоичные упаковки, экономящие каждый бит. Давайте загадим все интернет каналы под завязку. Пусть это происходит все быстре и быстрее.

Пусть наши заказчики побыстрее увидят, что не выгодно покупать неэффективный (большой, неповоротливый) софт. Так же, как неэффективно ездить по городу на машине, сжигающей 30 литров на 100 киллометров. Так же, как неэффективно использовать 100W лампочку накаливания там, где достаточно использовать 20W галогеновую. Сделаем же так, чтобы рост вычислительной мощности ЭВМ не успевал за прожорливостью нового ПО. Пусть часть работы программиста окажется дешевле часа работы написанной им программы. Раза эдак в три, или в четыре.

Вот тогда наступит наше время.

А пока, не своевременный совет вы даете, уважаемый тов.Павел Дворкин. Эдак вы наши планы раньше времени раскрываете. Демаскируете вы нас, однако.

Жаль только жить в это времы прекрасное уж не придется ни мне, ни тебе...

...поскольку крупные поставщики ПО в сговоре с железячниками — что б было как в анекдоте: кончилась водка, осталась закуска, сбегали за водкой, кончилась закуска, купили закуски...

Эффективное ПО также ненужно корпорациям как:
— вечная лампочка (почти вечная придумана давно)
— туфли на неснашиваемой подошве (казалось бы — чего проще пустить туда резину как в авто-покрышках)
— экономичные автомобили
— удобные и дешевые сотовые телефоны

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

PD>Собрался наконец написать. Минусов мне за эти тезисы поставят, это уж точно. Ну
PD>что же — к счастью, я уже не в том возрасте, когда падение или рост рейтинга
PD>могут серьезно повлиять на самочувствие.
Минус — это знак несогласия с сообщением, а не рейтинга. А в таком большом посте, трудно найти вещь с которой абсолютно несогласен.

PD> И действительно, как было не признать! Пока программа небольшая и в память
PD>помещается — ладно, живите и радуйтесь! Ну а как побольше стала ? Тут-то и
PD>придется признать свое бессилие. А гуру, им что, всегда что-нибудь придумают.
PD>Кто-нибудь из нынешнего поколения слышал про "самоубийство программ" ? Нет, это
PD>не стирание EXE-файла во время его работы. Это когда программа во время своей
PD>работы использует память, занятую своими командами (которые уже отработали и
PD>больше не потребуются) под свои данные.
У меня это называлось overlay.

PD> В общем, если говорить серьезнее, эффективность у нас была всегда на
PD>первом плане. Не как-нибудь написать, а наиболее эффективным способом,
PD>не любой алгоритм использовать, а лучший для этого случая. На этом мы
PD>прочно стояли.
Эффективность бывает разной. Можно написать программу, которая будет выполняться в 100 раз быстрее, но и содержать в 100 раз больше ошибок. И отладить эти ошибки будет практически невозможно. Поэтому эффективность — это не только скорость и потребление ресурсов.

PD> Чудо называлось Turbo Pascal 1.0. Сказать, что он меня поразил — не то
PD>слово. И не меня только. Все, кто до этого Ямаху не видел (а их в Омск
PD>очень немного попало тогда) и кому я о нем говорил, отвечали мне одинаково-
PD>такого не может быть!
Ага, и встроенный бейсик в Ямахе тоже был.

PD> А потом компьютеры, хоть и не меньше и не больше по размерам стали, начали
PD>резко увеличивать свою память и быстродействие. Сейчас любят вспоминать
PD>пророчество Б.Гейтса — дескать, 256 Кбайт всем хватит.
Вообще-то Билли говорил о 640.

PD> Вот тут первые шаги в сторону пренебрежения оптимальностью уже и начались.
PD>Действительно, на машине 600 Кбайт свободно, машина однопрограммная,
PD>конкурентов нет, зачем мне пытаться программу в 100 Кбайт уложить ,если можно
PD>все 500 спокойно использовать. Впрочем, память памятью, а есть еще и
PD>быстродействие. Оно было еще очень маленьким, так что хотя бы в этом
PD>плане писать все же приходилось эффективно, выжимать из машины все, что можно.
PD>Так что писать старались все же эффективно, хотя десятком, а то и сотней
PD>лишних Кбайт уже не мелочились.
Ну да. Только памяти никогда не хватало. И задачи, которые надо было реализовать, становились все больше и функциональнее. И потом все эти перегрузки памяти из extented в expanded. Все ради эффективности программы. Но самое главное, можно было быть уверенным за 400 килобайт нормальной памяти, и что тебе никто в соседнем процессе мешать не будет. Если было больше 400, то у многих клиентов программы отваливались. Для запуска некоторых программ, приходилось здорово подредактировать config.sys и autoexec.bat. Так что абсолютного счастья тогда не было.

PD> Дудки вам, а не 640 Кбайт. В 640 Кбайт сейчас умеют только "Hello,
PD>World" укладывать! Пока несколько десятков Мбайт не будет, и не подходите.
Ты Турбо-Vision пользовался? Достаточно эффективная библиотека, с очень большими возможностями. Но из-за того, что возможностей много то занимала много обычной и самой дорогой conversional memory. Поэтому, либо пиши все ручками (это будет эффективно по скорости и памяти), либо используй библиотеку и борись за память. А потом проблемы ушли. Может это и к лучшему?
Я тоже горячился когда оказалось что exe файл для Delphi был больше мега(сейчас не помню, но для тех времен очень много). Но то, что я мог мышью быстро собрать приложение и получить за него деньги перевешивало. Как программисту который уважает свое творчество, это плохо. А вот для человека который пытается на хлеб масло намазать, чрезвычайно хорошо.

PD> Другой пример — сама Windows. Я прекрасно понимаю, что Windows NT 4 и
PD>Windows XP — не совсем одно и то же. Но та на 8 Мбайтах работала, а эта от
PD>128 нос воротит, подавай ей 256.
NT 4.0 на 8 мегабайтах не работала, а обслуживала саму себя. И то, если сервис паки не ставить.
PD>А ядро, вообще говоря, претерпело не такие уж большие изменения.
Так оно места то много не занимает. Оно действительно эффективно. А вот если говорить о сопутсвующих процессах, типа сервисов и т.д., или тех же картинок, то это и есть увеличение. С установкой сервис паков и добавления функциональности, ситуация выравнивается.
Хотя согласен, многое можно было-бы сделать пооптимальнее.

PD>программа занимала 8 Мбайт, если можно взять 64 ? Даже, пожалуй, наоборот-
PD>увидят, что твоя программа меньше памяти занимает, чем у конкурента — ну
PD>и решат, что та более крутая
Дудки, такого не было. Программа должна либо работать, либо не работать и тормозить. Это и есть показатель эффективности был, есть и будет.

PD> Я не против удобства и простоты. Я за. А вот что такое "достаточной" —
PD>извольте объяснить. Если машина однопрограммная — тогда, конечно, достаточно —
PD>если помещается в память и достаточно быстро работает. А в многопрограммной
PD>коммунальной квартире стоит еще и о других подумать. Потому как память хоть и
PD>большая, но не резиновая. И процессор пока что только один, как правило.
Если пользователь будет одновременно работать с моей программой, с 10 вордами, 50 акцессами, и 30 экселами одновременно, то у него моя программа будет тормозить. Скажи мне, это я в этом не виноват? Ты можешь сформулировать когда программу можно считать избыточной?

PD>Или вот другой пример — с умножением матриц
Вроде дошли до того, что здесь кэш процессора играет слишком большую роль.

PD>Правда, Рихтер тут же отмечает, что эта операция может оказаться слишком
PD>дорогой,да и не всегда возможной. Рихтер, безусловно, понимает, когда ее можно
PD>применять, а когда не стоит. Понимают ли это все разработчики под .Net ? Боюсь,
PD>что нет. Так что будут они этот способ использовать, не слишком задумываясь,
PD>скорее всего. Сериализуют двумерную матрицу размером в несколько Мбайт, и все
PD>дела
Это взгляд со стороны. Разработчики все понимают. Но понимают и другое. Здесь уже несколько раз обсуждалось. Ошибиться в том, что ты неправильно определил место торможения, потратил много времени и сил на работу которая не нужна, значительно хуже. Поэтому лучше сначало сделать, а потом заниматься выявлением узких мест. А также оптимизацией памяти, если ее оказалось недостаточно.

PD>Хороший, кстати, пример — ICQ. Написана она не на .Net ИМХО (давно
Жадные вы. Че вам памяти жалко?
Во первых, ICQ — это глюк официально выходящий в альфа-бета видах. Притом накрученная функциональностей, которая особо никому и не нужна.
Во-вторых, не стоит по одной-двух программах делать выводы о отрасли в целом. Во времена MSDOS, были свои глюкавые монстры.

PD>Мне тут VladD2 упрек такой кинул — дескать, писать надо , не
PD>слишком думая об эффективности, а потом узкие места можно оптимизировать.
Подпишусь.

PD>Теоретически — совершенно безупречное рассуждение. А практически — это
PD>верно, если Вы заранее какой-то целью задаетесь — по памяти не более...
PD>или по времени не медленнее ... Если нет — никто и не будет оптимизировать,
PD>потому как совершенно непонятно, что и зачем. Работает каждый модуль раз в
PD>5 дольше , чем можно было бы, памяти кушает раз в 5 больше, чем надо было
PD>бы — что тут оптимизировать? Так и должно быть, все нормально сделали!
Будет. Важно даже не то, что в бумажках написано. Важно доволен ли пользователь программы. И хорошо ли ты написал, плохо ли, — клиент всегда прав. Ты можешь выжать 100 процентов оптимизации, но клиенту будет этого мало. И нравится тебе или не нравится, считаешь ли ты это нужным, или не считаешь, ты обязан это сделать. И тут никого не волнует даже то, умеешь ли ты оптимизировать, или не умеешь. Не умеешь, с голоду помрешь.

PD>В результате получаем некую самодвижущуюся повозку размером с аэроплан,
PD>ставим на нее ракетный двигатель, запускаем — едет! Едет ведь! Со скоростью
PD>60 км/час. Ну вот это и есть настоящий аэроплан, в серию его и пусть
PD>по дорогам ездит. А когда этим разработчикам объясняешь, что аэроплан
PD>должен не ездить, а летать, и не 60, а 900 км/ч давать, а если Вы автомобиль
PD>делали, то он и при двигателе внутреннего сгорания должен эти 60 (а то и 120)
PD>давать, да и размерами должен быть раз в 20 меньше — удивляются, чего, мол,
PD>привязался! Ездят же на нем, чего тебе надо!
Аналогия неуместна. Важно насколько клиенту важно чтобы он летал. Зачастую заказывают атомную подводный крейсер, а тебе выкатят Ту155 с 5 подводными винтами. И вроде двигается быстрее чем нужно. И летает, что не заказывали. И вроде винты красивые и их больше чем нужно. Но не плавает. Ну не успели научить.

PD> Создается впечатление, что рост быстродействия процессоров несколько
PD>замедлился. Может быть, я не прав, но мне кажется, что мы подошли к некоторому
PD>пределу, и если не последует технологического прорыва, то скорость сильно расти
PD>не будет. Еще раз — может быть, я не прав. Кстати, о памяти пока в этом плане
PD>говорить не приходится.
Не согласен. Уже вверх перестали развиваться такими темпами. Зато начали развиваться вширь.(двухядерные процы)
PD> Но так или иначе — этот предел есть. Очень уж четкие физические
PD>законы здесь действуют, их не обойдешь. Раньше или позже, но бурный рост
PD>мощности ПК заменится если не стагнацией, то более или менее плавным изменением,
PD>на проценты, а не в разы.
Это только что обсуждалось в соседнем топике.

PD> Не согласны ? OK, кто из вас взялся бы написать "Turbo Pascal 1.0"
PD>образца 2005 года? Который будет работать в такой маленькой памяти — 512 Мбайт
PD>и на таком медленном процессоре с частотой всего 3 GHz ? Боюсь, что Вы
PD>потребуете для этого 16 Gb памяти и не менее 30 GHz . Вы же прекрасно знаете,
PD>какие ресурсы для чего требуются, поэтому оцените их для этой задачи и получите
PD>16 Gb и 30 GHz, А где их взять? Впрочем, нет, не потребуете. Вы даже задачу
PD>такую не поставите — Вам она и в голову не придет: Боюсь, что мы даже и не
PD>узнаем, что могло бы быть написанным, если бы это эффективно делалось...
Не забывай. Компилятор Турбо-Паскаля практически полностью написан на ассемблере. И не от хорошей жизни. А письмена на ассемблере, даже тогда считались делом излишним и слишком крутым для повседневных задач. Попробовал бы ты описать паскаль в самом паскале. Тогда бы ты точно не запихнул это в 64 кил.
А на 512 легко. Но вопрос в другом. Если ты пишешь компилятор паскаля, то можно и в мег запихнуться. Но если ты будешь писать сервер приложений, и уместился в мег, то тебя в первую очередь должны выгнать. И я буду первым бежать и махать поганой метлой. Если тебе дали компьютер, с гигабайтом памяти, и с несколькими процессорами, то повышай эффективность используя все что тебе дали. Делай большие кэши, пользуй несколько потоков.

PD> Ну и к чему автор призывает, спросите Вы ? К поголовному возврату на
PD>ассемблер
PD>и к 64 Кбайтам ? К отказу от того пути, по которому сейчас пошло развитие ?
Знаешь, мне как программисту хочется вернуться туда. Все было интересней. Компы знали как свои пять пальцев. Но вот как главу семейства — ни в коем случае.
Я живу в своем времени. Если понятия эффективности изменились, то я их принимаю. Я делаю программный продукт, а не поделку для удовлетворения собственного эго. Я могу написать Паскаль на 64 килобайта. Но не буду. Не потому что это сложно. Ничего сложного в этом нет. Нужно просто уметь выжимать 100 процентов из компилятора и архитектуры. Это просто никому не нужно. Времена 64 килобайт прошли. Сейчас стало легче жить. И это хорошо.

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
PD>это возможно!
Слишком абстрактно. Надо сначало описать, что такое эффективность. Именно в нынешние дни.

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

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

E>Пусть наши заказчики побыстрее увидят, что не выгодно покупать неэффективный (большой, неповоротливый) софт.
Интересно почему когда говорят что большой, сразу ассоциируют с неэффективным. Если у меня камаз возит кирпичи, то это лучше чем жигуленок. Хотя жигуленок меньше топлива жрет. Другое дело когда Белазом пытаются в такси поиграться. Конечно светофоры полегче проезжать, но солярки жрет, немерено.

А ты дать определение, что такое эффективный софт. И что такое неэффективный софт?
С уважением, Gleb.

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

PD>Мне тут VladD2 упрек такой кинул — дескать, писать надо , не
PD>слишком думая об эффективности, а потом узкие места можно оптимизировать.
PD>Теоретически — совершенно безупречное рассуждение. А практически — это
PD>верно, если Вы заранее какой-то целью задаетесь — по памяти не более...
PD>или по времени не медленнее ... Если нет — никто и не будет оптимизировать,
PD>потому как совершенно непонятно, что и зачем. Работает каждый модуль раз в
PD>5 дольше , чем можно было бы, памяти кушает раз в 5 больше, чем надо было
PD>бы — что тут оптимизировать? Так и должно быть, все нормально сделали!

А как вам вот такой тезис, что программа просто должна быть достаточно xxx?
Не надо выделять потребляемую память и быстродействие в отдельную категорию. Программа должна быть достаточно во всем и, в идеале, одинакого. Далее неупорядоченный список: достаточно функциональна; достаточно удобна; достаточно устойчива; достаточно мало жрать память; достаточно быстро работать; если проект после 1.0 не планируется отправить в архив то достаточно сопровождаема; и т.д. А скорость эскадры равна скорости самого медленного корабля.

Я ни в коем случае не призываю не думать об эффективности, не искать всегда и везде лучшие подходы и алгоритмы. Я предлагаю не думать об этом больше/чаще, чем о, например, удобстве UI или чистоте и последовательности архитектуры. Не забывать, что как бы быстро прога не работала, она будет бесполезна, если пользователь не сможет решить с ее помощью свои задачи.

Что касается непонимания в глазах начинающих, то это непонимание бывает в всех вопросах и оптимальность далеко не единственный из них, хотя, похоже, для Вас лично, самый больной. Но тут для того и нужен Учитель, что бы проводить Ученика его (Ученика) путем в ближайший тупик и... оставить его там подумать.

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

GZ>А ты дать определение, что такое эффективный софт. И что такое неэффективный софт?

А еще определение "оптимизации" Это мне как-то на защите диссертации довелось побывать. Там человек защищался по инструментальной системе для кросс-ассемблерной разработки. Для того, чтобы очень сильная прикладная работа имела хоть какой-то оттенок научности в диссертацию вставили что-то про "оптимизацию разработке". И вот на защите бедолага диссертант взял да и ляпнул не к месту это слово. До этого дяденьки из совета чесно дремали, т.к. большинство из них слобо понимало, о чем вообще речь. А тут! Да у большинства из них оптимизация чего-то там -- это хлеб родной. Вот и спросили товарища: "Дайте определение оптимальной функции!"... Хорошо еще, что все хорошо закончилось.

Может давай я тебе еще пару примеров приведу к тому, что Павел у себя указал?

Вот берем браузер Opera. В нем еще и RSS-ридер есть, и почтовый клиент. И поиск по почте/сообщениям за доли секунды выполняется. И сам браузер 3.5Mb в дистрибутиве занимает (без Java). И памяти при работе у меня сейчас 44Mb занимает с 14-ю открытыми табами. Кому как, а по мне Opera весьма эффективная программа.

Возьмем Janus. Когда я пишу это сообщение он у меня занимает в пямяти 53Mb. Сам инсталлятор у него маленький, но к нему же еще и .Net нужен. А к следующим версиям еще и .Net 2.0 потребуется. А уж поиск по базе сообщений по скорости с Opera вообще не сравнится. Да и объем сохраняемых сообщений на диске не маленький. Так что для меня Janus удобная программа, но вот эффективной я ее назвать не могу. А если для повышения ее эффективности для хранения сообщений вообще что-то посерьезнее Jet-та потребуется (какой-нибудь FireBird или MSSQL), то вообще...

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


E>Вот тогда наступит наше время.

Тогда нас уже не останется. И никто не будет знать как писать простые и эффективные программы...

PD> Я не настолько наивен, чтобы к этому призывать. Просто одно скажу :

PD>Пишите свои программы эффективно, господа! По крайней мере настолько, насколько
PD>это возможно!
Давайте разберемся с критерием "насколько это возможно", судя по тому что подход используемый в индсутрии выраженный владом: "оптимизируй только там где это необходимо" смею предположить что вы проповедуете подход "чем больше тем лучше"?

А вы представляете сколько будет стоить такая программа?
И где набрать столько высококвалифицированных программистов?
И какое количество ошибок будет содержать такое highly optimized приложение?

В результате может получиться обратная ситуация:
у пользователя есть компутер с 300МHz тактовой частотой, 128Мб памяти, и
ОS windows Effective (tm) которая будет показывать чудеса производительности на данной конфигурации но одна лицензия будет стоить 15000$.

Имхо, индустрия сама отлично себя регулирует: пока труд программистов стоит дороже железяк — будет сохранятся текущая ситуация. Изменится соотношение — изменится и отношение

PS: приложений где нужны эффективные решения и тотальная оптимизация достаточно много.
Но для большинства десктоп приложений оптимизация и эффективность не нужна. Если мне предложат МС офис за 100$ но который при этом будет жрать ресурсов в два раза больше — я предпочту его, докупив нужное количество процессора и памяти

Необходимость в написании ну о-о-о-очень эффективных программ отпала. И слава богу. Туда и дорога.
Потому что единственными, кто был в этом заинтересован, были сами компьютерные энтузиасты (вроде вас, автор?), которые предпочитали ... э-э-э-э заниматься с компьютером любовью непременно стоя и непременно в гамаке.
А почти полная утеря общественностью навыков эффективного создания каменных топоров вас не волнует? А врдруг железо закончится, что делать будем?

Индустрия променяла эффективность кода на эффективность труда. И на его облегчение. Что тут плохого?

Описанная картина неизбежного апокалипсиса тоже сильно преувеличена.

Программы редко пишутся в расчете на то, что железо подрастет. Крупные игры, ОС и прочие перспективные разработки в основном. Мы же, простые прикладные смертные, имеем дело с тем, что есть. И выбор между экономией тактов и экономией человеко-часов стараемся делать однозначный.

Поэтому то, что есть.. java/.net, массивные framework-и и Windows XP никуда не денутся, даже если прогресс резко остановится.Эти вещи пришли, чтобы остаться. А если прогресс не замедлится, то мы постараемся занять и те ресурсы, что будут нам предоставлены. Зачем?

Понимаете, автор... гигабайт свободной оперативной памяти при запущенной IDE греет душу не всем. Мне, например, нет. А вот возврата к временам, когда редактор кода в IDE не умеет подсвечивать синтаксис и указывать на допущенные мной ошибки в background-е я не хочу.

И не надо мне говорить, что это не связанные вещи. Что компиляция в background-е была бы все равно, причем быстрее и надежнее. Ее бы не было именно потому, что ее пришлось бы писать на каком-нибудь asm-е с использованием столь эффектно описанного вами механизма самопожирания программы. Руки бы не дошли — надо было бы drag&drop прикручивать и баги в компиляторе исправлять. А может эту фичу вообще не стали бы делать — памяти ого-го сколько отжирает, целых 121 232 байта! В уме нужно компилировать, слабак!

За все нужно платить. Текущая плата лично мне представляется в высшей степени щадящей.

Кроме того, вы путаете причину и следствие. Проблема не в том, что основная масса "программистов" не умеет оптимизировать свой код. Проблема в том, что они вообще очень мало, что умеют, а обучаться не могут или не хотят.

Раньше было не так? Да, но раньше это была элитарная профессия. А теперь потребность в кодерах возрасла многократно (несмотря на то, что эффективность труда тоже) и уровень, разумеется, упал. И отсутствие оптимизации — это меньшее из всех зол.

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

E>Вот и спросили товарища: "Дайте определение оптимальной функции!"... Хорошо еще, что все хорошо закончилось.


E>Может давай я тебе еще пару примеров приведу к тому, что Павел у себя указал?

E>Вот берем браузер Opera. В нем еще и RSS-ридер есть, и почтовый клиент. И поиск по почте/сообщениям за доли секунды выполняется. И сам браузер 3.5Mb в дистрибутиве занимает (без Java). И памяти при работе у меня сейчас 44Mb занимает с 14-ю открытыми табами. Кому как, а по мне Opera весьма эффективная программа.
У меня впечатления строго наоборот. Была опера, правда старая(не помню версию, по моему 6). Строго отжирала 100мБ в лучшие дни. В худшие еще больше. Поэтому с Оперой, у меня строго обратные ассоциации.

Слушай, а сколько мег у тебя занимает база сообщений?

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

mrozov wrote

> Необходимость в написании ну о-о-о-очень эффективных программ отпала.
> И слава богу. Туда и дорога.
> Потому что единственными, кто был в этом заинтересован, были сами
> компьютерные энтузиасты (вроде вас, автор?), которые предпочитали ...
> э-э-э-э заниматься с компьютером любовью непременно стоя и непременно
> в гамаке.
> А почти полная утеря общественностью навыков эффективного создания
> каменных топоров вас не волнует? А врдруг железо закончится, что
> делать будем?
> Индустрия променяла эффективность кода на эффективность труда. И на
> его облегчение. Что тут плохого?

Ошибаетесь, вот МС показала здравый смысл — в Windows Vista все как и
раньше будет основано на unmanaged-приложениях. В том числе и explorer с
оффисом. И пока программисты, ратующие за увеличение производительности
труда, будут писать чего-то там на WinForms или Avalon'е — МС будет
совершенствовать свой набор оффисных программ, интегрированных через
OLE2 (аналога которого в managed-мире нет и не предвидится).

--
С уважением,
Alex Besogonov (alexy@izh.com)

It is far, far easier to make a correct program fast than it is to make a fast program correct. (c) C++ Coding Standards: 101 Rules, Guidelines, and Best Practices

Ну и от себя (хотя тоже не мое):

Заказчик: Нам нужна программа, которая будет стоить не дорого, работать — быстро, и сделать ее надо срочно.
Программисты: Из трех перечисленных условий выберите любые два.

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

E>>Вот берем браузер Opera. В нем еще и RSS-ридер есть, и почтовый клиент. И поиск по почте/сообщениям за доли секунды выполняется. И сам браузер 3.5Mb в дистрибутиве занимает (без Java). И памяти при работе у меня сейчас 44Mb занимает с 14-ю открытыми табами. Кому как, а по мне Opera весьма эффективная программа.
GZ>У меня впечатления строго наоборот. Была опера, правда старая(не помню версию, по моему 6). Строго отжирала 100мБ в лучшие дни. В худшие еще больше. Поэтому с Оперой, у меня строго обратные ассоциации.

Ну, 7-ка и 8-ка весьма экономичные. А 6-ку я уже и не помню.

GZ>Слушай, а сколько мег у тебя занимает база сообщений?

~252Mb.
Но у меня еще и года использования Janus не прошло, да и подписан я всего на 7 форумов.

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

DAN>Давайте разберемся с критерием "насколько это возможно", судя по тому что подход используемый в индсутрии выраженный владом: "оптимизируй только там где это необходимо" смею предположить что вы проповедуете подход "чем больше тем лучше"?

Я абсолютно согласен с ортимизацией "где надо", речь не об этом. В исходном посте посте говорилось о тенденции, о появившихся привычках и том, что понятие "оптимальный" просто забывается, уходит вслед за 1Mhz компами и 640Кb памяти. И что эта тенденция очень может выйти боком в свете физических пределов GHz и Gb.