Здравствуйте, Павел

С удовольствием прочел бурную дискуссию. Сейчас у нашей команды проблема производительности стоит остро. Расскажу все как есть. Мы занимаемся обработкой огромных потоков информации, которые поступают от крупнейшего бла-бла-бла. Работа одного из модулей состоит из чтения данных из файла, запись в БД, запуск нескольких SP на БД и последнее запись результатов снова в файлы. Модуль обязан работать быстро, качественно и далее по оранжевой книге...
Модуль написан на С++ и использует практически все "крутые фитчи" от STL, Boost, Log4cpp, DP, Oracle... Я бы сказал, что код написан не просто на высоком уровне, на высочайшем, так как приняты во внимания практически все рекомендации заслуженых профи в этих областях (Саттер, Мэйерс, Кайт...). Вобщем вы поняли, нарекания на дизайн не может быть, просто физически не к чему прикопатся.

Так вот, мы посчитали, что 25 тыс. загруженых (5Мб файл) записей из CDR-файлов(для тех кто с биллингом не работал, это такие CSV-файлы) с обработкой и последующей записью занимает 2 мин. 14 сек. Далее характеристики двух дней оптимизации:

Точка отчета:                                 2 мин. 14 сек.
(А)Очередь симметричных запросов:             2 мин. 05 сек.
(АР)Резервирование памяти, под 
    "узнаваемые" данные:                      2 мин. 00 сек.
(А)Замена map vector-м                        1 мин. 54 сек.
(АР)Замена строк хэшем                        1 мин. 30 сек.
(АР)Запись в файл через буфер строк,
    вместо записи vector-а строк в поток      42 сек (запись в 5 МБ в файл=0.05 сек)
(А+АР)далее...:                               15 сек

АР — архитектурное решение примененено,
А — применен алгоритм
Если раньше модуль накапливал данные днем и обрабатывал ночью, то теперь он все успевает, более того модуль отдает больше CPU времени для своих нужд. Для нас вышло, что выигрыш одной сек на операции — это выйгрыш ~12 мин в день. Это здорово, так как заказчики "писают кипятком", а "конкуренты кусают локти"

PS: Все началось с того, что мне сказали, что якобы кто-то где-то видел "крутую программу", которая выгружает 1 млн. записей в CSV-файл за 1 сек. Я не поверил, но призадумался.

PPS:
$uname -X
System = SunOS
Release = 5.9
KernelID = Generic_117171-08
Machine = sun4u
NumCPU = 20

$top
Memory: 160G real, 79G free, 60G swap in use, 101G swap free

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

TK>Может, лучше архитектора? Откуда такое мнение, что хорошо спроектированное приложение обязательно будет работать медленно?

Давай проведем эксперимент. Итак, код:

public abstract class LoaderBase : ILoader
{
    private const string s_SchemaResourceName = "Parus.MetadataModel.Model.TornadoMetadata.xsd";
    private static XmlSchema s_MetadataSchema;

    private static XmlSchema GetMetadataSchema()
    {
        if (s_MetadataSchema == null)
            using (Stream s = typeof (LoaderBase).Assembly.GetManifestResourceStream(s_SchemaResourceName))
                s_MetadataSchema = XmlSchema.Read(s, null);
        return s_MetadataSchema;
    }

    /// <summary>
    /// Смотри <see cref="ILoader.Load(string, IMetaResolver)"/>.
    /// </summary>
    public XmlDocument Load(string src, IMetaResolver resolver)
    {
        XmlValidatingReader valRdr = new XmlValidatingReader(new XmlTextReader(new StringReader(src)));
        valRdr.Schemas.Add(GetMetadataSchema());
        XmlDocument doc = new XmlDocument();
        doc.Load(valRdr);
        return doc;
    }
}

Известно, что работу метода Load можно ускорить на несколько порядков, изменив исходник совсем чуть-чуть. Вопрос в том — что и как надо изменить.
Теперь давай посмотрим, сколько из здесь присуствующих, не запуская профайлера, смогут понять в чем здесь проблема. Можешь еще поспрошать вашего крутого спеца по .NET, который любит народ на собеседованиях заваливать.

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

AVK>Давай проведем эксперимент.

А можно и мне попробовать?

AVK>

AVK>public abstract class LoaderBase : ILoader
AVK>{
AVK>    /// <summary>
AVK>    /// Смотри <see cref="ILoader.Load(string, IMetaResolver)"/>.
AVK>    /// </summary>
AVK>    public XmlDocument Load(string src, IMetaResolver resolver)
AVK>    {
AVK>        XmlValidatingReader valRdr = new XmlValidatingReader(new XmlTextReader(new StringReader(src)));
AVK>        valRdr.Schemas.Add(GetMetadataSchema());
AVK>        XmlDocument doc = new XmlDocument();
AVK>        doc.Load(valRdr);
AVK>        return doc;
AVK>    }
AVK>}
AVK>

Выделенное жирным обязательно на каждом вызове Load делать?

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

E>Выделенное жирным обязательно на каждом вызове Load делать?

Да, ValidatingReader работает только в одну сторону.

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

TK>>Может, лучше архитектора? Откуда такое мнение, что хорошо спроектированное приложение обязательно будет работать медленно?

AVK>Давай проведем эксперимент. Итак, код:

Это ты про то, что если добавлять не схему а коллекцию схем то, это будет эффективнее?

AVK>Известно, что работу метода Load можно ускорить на несколько порядков, изменив исходник совсем чуть-чуть. Вопрос в том — что и как надо изменить.

Несколько порядков это в 100раз минимум. я правильно понял?

AVK>Теперь давай посмотрим, сколько из здесь присуствующих, не запуская профайлера, смогут понять в чем здесь проблема.

Ты мне главное объясни — причем тут профайлер? Это статическая оптимизация (фактически обход глюков .NET) про нее надо просто знать и каждый раз реализовывать. Макаронным код она никак не сделает. Более того, в коллекцию можно будет добавить несколько схем что, может тоже пригодиться.

Или, ты каждый раз профайлер на этих строчках запускаешь? ИХМО, можно один раз понять (либо запомнить) а потом использовать.

В любом случае — как это относится к теме обсуждения?

PS
Кстати, GetMetadataSchema — это же ужас... Как насчет реализовать его по нормальному? К стилю я придераться не буду. Но, обычно singleton объекты реализуют в более "надежной" манере.

PPS
AVK>Можешь еще поспрошать вашего крутого спеца по .NET, который любит народ на собеседованиях заваливать.

Тебя же вроде как не валили? Откуда негатив-то?

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

TK>Это ты про то, что если добавлять не схему а коллекцию схем то, это будет эффективнее?

Ага

AVK>>Известно, что работу метода Load можно ускорить на несколько порядков, изменив исходник совсем чуть-чуть. Вопрос в том — что и как надо изменить.

TK>Несколько порядков это в 100раз минимум. я правильно понял?

Точных цифр я уже не помню, но где то так.

AVK>>Теперь давай посмотрим, сколько из здесь присуствующих, не запуская профайлера, смогут понять в чем здесь проблема.

TK>Ты мне главное объясни — причем тут профайлер?

Ни при чем. Вопрос в том как с таким бороться.

TK> Это статическая оптимизация (фактически обход глюков .NET) про нее надо просто знать и каждый раз реализовывать.

Все знать невозможно.

TK>В любом случае — как это относится к теме обсуждения?

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


TK>PS
TK>Кстати, GetMetadataSchema — это же ужас... Как насчет реализовать его по нормальному? К стилю я придераться не буду. Но, обычно singleton объекты реализуют в более "надежной" манере.

Это GUI приложение. Никаких потоков там нет.

TK>PPS
AVK>>Можешь еще поспрошать вашего крутого спеца по .NET, который любит народ на собеседованиях заваливать.

TK>Тебя же вроде как не валили? Откуда негатив-то?

Нелюблю таких. Но это уже оффтоп.

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



настаиваю на введение трехбальной системы оценок в сторону юмора на rsdn.

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

TK>>Ты мне главное объясни — причем тут профайлер?
AVK>Ни при чем. Вопрос в том как с таким бороться.

Этот случай надо запомнить. Хотя, можно было-бы и на этапе проектирования прикинуть, что валидация сложного XML документа может быть достаточно ресурсоемким заданием.

TK>> Это статическая оптимизация (фактически обход глюков .NET) про нее надо просто знать и каждый раз реализовывать.
AVK>Все знать невозможно.

Никто не спорит. Просто в данном конкретном случае заниматься оптимизацией всего приложения было бы ошибкой. Решать всегда надо какую-то конкретную задачу (это если конечно в оригинальном дизайне уверен :). В данном случае оптимизировать надо было только метод Load

TK>>В любом случае — как это относится к теме обсуждения?

AVK>Относится очень просто — как пример того, что этот маленький кусочек кода способен сделать бесполезными горы оптимизаций, причем от таланта архитектора или программиста это практически не зависит.

Именно по этому, надо нормально писать даже самые маленькие кусочки. А не заниматься экономией LOCов.Ну и стараться что-бы все кусочки были легко заменяемы тогда, в случае проблем, отдельные части можно заменить более оптимальными версиями не приводя остальные части приложения в макаронный код.

TK>>PS
TK>>Кстати, GetMetadataSchema — это же ужас... Как насчет реализовать его по нормальному? К стилю я придераться не буду. Но, обычно singleton объекты реализуют в более "надежной" манере.

AVK>Это GUI приложение. Никаких потоков там нет.

Сегодня нет, а если завтра появятся? Или, у вас компания поставила цель экономить каждый LOC взамен более надежному коду? Собственно, подход к оптимизации примерно так по мелочам и проявляется — тут схалтурил, там написал кое-как...


TK>>Тебя же вроде как не валили? Откуда негатив-то?
AVK>Нелюблю таких. Но это уже оффтоп.

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

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

TK>Никто не спорит. Просто в данном конкретном случае заниматься оптимизацией всего приложения было бы ошибкой. Решать всегда надо какую-то конкретную задачу (это если конечно в оригинальном дизайне уверен . В данном случае оптимизировать надо было только метод Load

Конечно не надо тратить месяц и делать некую конкретную функцию в конкретном проекте быстрее в 100 раз, если за цикл работы она вызывается 2 раза и работает 0,001 сек.
Проблема возникает, когда такой код начинают реюзать в других проектах — в ситуациях когда он вызывается 1000000 раз.
А с первого взгляда не скажешь, да и не пишут в комментариях "эта ф-ция не оптимизировалась".

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

GZ>Смотришь — тормозит. Ага, вот здесь оптимизировали — тормозит. А вот здесь оптимизировали — тормозит. Вот здесь оптимизировали — не тормозит.

Ну, такое только в сказке бывает. А теперь, представь что оптимизируется бизнес приложение проблемы с которым обнаружились только в pruduction и только под большой нагрузкой. Второго такого железа нет а запуск профайлера, на рабочей системе предполагает то, что больше половины пользователей не смогут ей пользоваться...

TK>>Кроме того, профайлер сам вносит достаточную погрешность в измерения
GZ>Это хреновый профайлер, или неумение им пользоваться.

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

TK>>не каждое приложение можно запустить под профайлером и получить адекватные результаты.
GZ>Бывает. А вот для этого логи никто не отменял. ;)

Гланое, что-бы они тормозить не начали ;)

TK>>Думаю, что алгоритм сортировки пузырьком как не точи ничего хорошего не выйдет...
GZ>Ай-ай-ай. Попался на пустом месте. Пузырек очень эффективен если список уже почти отсортирован.

Правильно. Потому Дворкин и пишет, что дума надо. Вполне возможно, что сортировка вообще не нужна если данные хранить в уже отсортированном виде :)

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

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

GZ>>Смотришь — тормозит. Ага, вот здесь оптимизировали — тормозит. А вот здесь оптимизировали — тормозит. Вот здесь оптимизировали — не тормозит.
TK>Ну, такое только в сказке бывает.
Нее в жизни. У меня как только торможение появляется, так мыслей 10-20 сразу же, где это может быть. Половина из них — неправильные.

TK>А теперь, представь что оптимизируется бизнес приложение проблемы с которым обнаружились только в pruduction и только под большой нагрузкой. Второго такого железа нет а запуск профайлера, на рабочей системе предполагает то, что больше половины пользователей не смогут ей пользоваться...
TK>Ну, например профилируем веб сайт... Второго такого железа у нас нет и потому профилируем по живому. Запустили профалер все начало тормозить, запросы начали отваливаться по таймауту. Что на это делают пользователи? делают рефреш на первую страницу. В итоге, мы получаем замечательную статистику для оптимизации первой страницы — нагрузка на которую в обычное время не такая уж и большая. И оптимизировать ее совершенно не нужно...
Ну-ну-ну. Не надо по живому. Лучше организовать нагрузочное тестирование на левом железе. Некоторые проблемы выявишь сразу, будет меньше ответсвенной работы.

TK>>>не каждое приложение можно запустить под профайлером и получить адекватные результаты.
GZ>>Бывает. А вот для этого логи никто не отменял.
TK>Гланое, что-бы они тормозить не начали
Смотря как напишешь. У меня одним пользователям так понравились мои дебужные логи, что они решили их не отключать. Нагрузка на логи не сравнить с нагрузкой на web-сайт.

TK>>>Думаю, что алгоритм сортировки пузырьком как не точи ничего хорошего не выйдет...
GZ>>Ай-ай-ай. Попался на пустом месте. Пузырек очень эффективен если список уже почти отсортирован.
TK>Правильно. Потому Дворкин и пишет, что дума надо. Вполне возможно, что сортировка вообще не нужна если данные хранить в уже отсортированном виде
Или наоборот. Окажется что quick sort хоть и тормозит, но выполняется раз в год и у него на входе 3 объекта. Хотя это действительно алгоритмическая оптимизация, и ею надо заниматься до реализации.

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

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

PD>Следует ли из этого, что читать побайтно вообще нельзя ? Ни в коем случае!

Ты не поверишь, но сегодня чтению и побайтно и поблочно я скорее всего предпочту сервер базы данных

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

TK>Есть вещи на понимание которых надо изначально потратить какое-то время (обычно этому и учат в институтах) а потом, эффективно их использовать.

Какие вещи? Читать блочно? А в институтах только этому учат или там рассматривают все возможные варианты? Я вот, например, сходу могу предложить с десяток способов как это можно сделать. В институте рассматриваются все эти способы, рассматриваются их достоинства и недостатки? Сравниваются ли эти способы в контексте конкретных приложений или только в контексте СКВВ? Делаются ли всегда однозначные выводы или многозначные? Чему собственно учат в институте по-твоему?

TK>Вобщем, не слушайте Влада — еще не того насоветует (он тут рядом вообще кончину Win32 предрекал

Да ты там тоже землицы в могилку побрасывал, так-что не надо

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

0rc>Далее характеристики двух дней оптимизации:

Интересная статистика.

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

1. Загрузка и обработка 3-х гигабайтного файла телефонных транзакций в БД. Примерно 11 млн записей. Переход на BULK INSERT (с самого начала не хотелось с ним связываться) — ускорение в 80 раз. Сокращение времени загрузки с 2.5 суток до 48 минут.
   
2. Перенос логики обработки данных одного отмороженного отчёта с C++ на T-SQL. Там надо было много и непонятно группировать. Были задействованы все возможные самые плохие практики T-SQL включая временные таблицы и циклы. Сокращение времени с 4-х часов до 18 минут за счёт исключения множественных обращений к серверу.
   
3. Расчёт начисления платежей. Переход с обработки данных record-by-record на обработку массивами. Опять же T-SQL. Использовалось много временных таблиц, но в расчётах ни одна запись не обрабатывалась индивидуально. Т.е. если что-то умножалось на 2, то это были десятки тысяч записей. Порядка двух десятков стадий вычислений. Количество master-records в основной таблице около полумиллиона. Сокращение работы с 40 минут до 2.5 минут.
   
4. Замена алгоритма сортировки большого списка документов (~50k) с честного алгоритма сортировки на единственный проход по заранее отсортированному списку по заранее определённым критериям. Было несколько секунд, стало незаметно на глаз.
   
5. Переход с поблочного чтения данных из файлов на отображаемые файлы. Увеличение скорости в 3 раза и как результат уменьшение скорости обновления данных с 20-25 минут, до 7-8. Но не тут-то было Всё замечательно работало на NT и жутко тормозило на W95. Проблема решилась тупым прогоном отображения через небольшой участок памяти.
   
6. Сокращение размера индекса в самопальной БД с 4-х байт до 3-х Экономия 100MB на диске, что позволило уложить базу данных на сидюк.
   
7. Использование в качестве данных при моделировании двух больших массивов. По сути, две громадные структуры, одна на начало такта, другая типа текущие данные. Синхронизация делалась простым memcpy. Для этого пришлось написать свой компилятор, который вкладывал туда даже то, что сегодня называется метадатой. Результат — конкуренты перестали заниматься подобными системами
   
8. Перекрытие и реализация своего собственного метода new типа как у Влада в статье про Quick Heap. Ускорение подготовки отчёта в десятки раз. Что-то там у борландовского хипа не сложилось тогда. Похоже, что от фрагментации у него крыша поехала.
   
9. В RFD (ну куда же без него ) замена рефлекшина на имит позволила сократить время маппинга в 3-5 раз и догнать по производительности датасеты и ридер.
   
10. Принудительная реаллокация памяти для stl вектора. Сокращение расходуемой памяти с 100 мег до 20-ти.

В принципе, последняя оптимизация была не столько оптимизацией, сколько фиксом стандартного stl'евского бага. Подобных мелких оптимизаций всегда много. Подавляющее большинство подобных вещей решается кеширование. Но это не очень интересно.

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

IT>

В RFD (ну куда же без него ) замена рефлекшина на имит позволила сократить время маппинга в 3-5 раз и догнать по производительности датасеты и ридер.
IT>

Принудительная реаллокация памяти для stl вектора. Сокращение расходуемой памяти с 100 мег до 20-ти.
IT>[/list]

IT>В принципе, последняя оптимизация была не столько оптимизацией, сколько фиксом стандартного stl'евского бага. Подобных мелких оптимизаций всегда много. Подавляющее большинство подобных вещей решается кеширование. Но это не очень интересно.

Таких списков можно насоставлять море. Дело то не в этом. Народ ругается похоже по другому поводу. Просто слово "ОПТИМИЗАЦИЯ" имеет несколько смысловых значений. На вскидку попытаюсь предложить несколько (применимо к разработки), сильно не критикуйте.

1. Оптимизация, которая делается только тогда когда что-то (модуль программный) работает не так, как нам это нужно (пользователям). Т.е. тормозит, память отжирает и т.д. Ищем узкие места профайлером. То, за что агитирует со страшной силой Влад2 (кстати, а почему 2???)
2. Выбор оптимальных путей кодирования. То есть когда нужно использовать ArrayList, а когда LinkedList, а когда вообще HashMap. Ну это к примеру. Причем делаем мы это неосознанно.
3...
4...

Вот и получается, что сравнивать 1-й пункт со 2-м некорректно, участники же дискуссии пытаются сделать судя по всему именно это.

P.S. А может тут еще какая-то засада?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

PD>>Следует ли из этого, что читать побайтно вообще нельзя ? Ни в коем случае!

IT>Ты не поверишь, но сегодня чтению и побайтно и поблочно я скорее всего предпочту сервер базы данных

Может быть, ты и прав. Кстати, если MS реализует свою файловую систему а ля SQL сервер, то между чтением побайтно и поблочно, с одной стороны, и сервером БД просто разницы не будет , потому как ФС и будет БД

Если же оставаться на нынешней стадии, то все же ИМХО скорость БД будет поменьше. Подчеркиваю — ИМХО, это не личный опыт, а скорее отзывы, какие я получил. Я, когда над своим проектом начал работать (а было это 4 года назад) первым делом задал вопрос в фидо конференции по БД — так и так, есть такие-то данные, можно ли с помощью БД получить доступ за 50-70 мсек, если да — какую БД посоветуете ? Ответ был единодушный — нет. Может, они не правы были, к тому же с тех пор прошло 4 года...

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

TK>Этот случай надо запомнить.

Все не упомнишь.

TK> Хотя, можно было-бы и на этапе проектирования прикинуть, что валидация сложного XML документа может быть достаточно ресурсоемким заданием.

Можно. Только это не помогло бы. Каким бы не был медленным валидатор, он явно не должен тратить несколько секунд на валидацию пары десятком килобайтных XML-файлов.

TK>>> Это статическая оптимизация (фактически обход глюков .NET) про нее надо просто знать и каждый раз реализовывать.
AVK>>Все знать невозможно.

TK>Никто не спорит. Просто в данном конкретном случае заниматься оптимизацией всего приложения было бы ошибкой. Решать всегда надо какую-то конкретную задачу (это если конечно в оригинальном дизайне уверен . В данном случае оптимизировать надо было только метод Load

А никто и не занимался. Тормозила определенная операция. Запустили профайлер — обнаружили что метод XmlSchemaCollection.Add жрет 99% времени, что, мягко говоря, странно. Полезли в рефлектор, удивились еще больше. Поправили и получили ускорение на пару порядков минимум.

AVK>>Относится очень просто — как пример того, что этот маленький кусочек кода способен сделать бесполезными горы оптимизаций, причем от таланта архитектора или программиста это практически не зависит.

TK>Именно по этому, надо нормально писать даже самые маленькие кусочки.

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

TK> А не заниматься экономией LOCов.Ну и стараться что-бы все кусочки были легко заменяемы тогда, в случае проблем, отдельные части можно заменить более оптимальными версиями не приводя остальные части приложения в макаронный код.

Вот, золотые слова.

AVK>>Это GUI приложение. Никаких потоков там нет.

TK>Сегодня нет, а если завтра появятся?

Не появятся. Городить double check locking на всякий случай имхо перебор. И производительность это, кстати, ухудшит.

TK>>>Тебя же вроде как не валили? Откуда негатив-то?
AVK>>Нелюблю таких. Но это уже оффтоп.

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

А я не тебе, я тому товарищу, просто напрямую обратится не имею возможности.

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

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

И не скажу, не жди. Потому как вопрос из той же серии — что лучше : список или массив ?

Иногда (в моей задаче, к примеру) надо бывает оптимизировать по скорости, а с памятью меня никто особенно не напрягал. Я об этом, кстати, говорил — занял бы еще несколько десятков или сотню Мб — никто бы слова не сказал, а вот за 200 мсек на запрос выгнали бы. А иногда — прямо наоборот, скорость вообще несущественна (та же ICQ, к примеру , где ее вообще по скорости можно оптимизировать, когда скорость определяется интернетом, да и там в основном SMS шлются — short пакеты, так сказать), а вот памяти я ей бы позволил заниимать не более 500 Кбайт при обычной работе (ну а при прочих действиях, так и быть, 1 Мб позволил бы . (И то, 500 Кбайт — это снисходя к современным аппетитам, реально ей и 100 не надо . Потому что в данном случае это мелкая приблуда на моем PC, и ее наличие я вообще в смысле потребления памяти должен просто не замечать.

Кстати, у VC компилятора есть несколько базовых режимов оптимизации — Minimal size, Maximum Speed. К чему бы это ? . Они что-то тоже не хотят сказать, что важнее.

Здравствуйте, Кузнецов Денис Викторович, Вы писали:

КДВ>Таких списков можно насоставлять море.

Так вот и надо их насоставлять. И боюсь блочного чтения там может и не оказаться

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

PD>И не скажу, не жди. Потому как вопрос из той же серии — что лучше : список или массив ?

Но тогда как следовать твоему лозунгу?

PD>Иногда (в моей задаче, к примеру) надо бывает оптимизировать по скорости, а с памятью меня никто особенно не напрягал. Я об этом, кстати, говорил — занял бы еще несколько десятков или сотню Мб — никто бы слова не сказал, а вот за 200 мсек на запрос выгнали бы. А иногда — прямо наоборот, скорость вообще несущественна (та же ICQ, к примеру , где ее вообще по скорости можно оптимизировать, когда скорость определяется интернетом, да и там в основном SMS шлются — short пакеты, так сказать), а вот памяти я ей бы позволил заниимать не более 500 Кбайт при обычной работе (ну а при прочих действиях, так и быть, 1 Мб позволил бы . (И то, 500 Кбайт — это снисходя к современным аппетитам, реально ей и 100 не надо . Потому что в данном случае это мелкая приблуда на моем PC, и ее наличие я вообще в смысле потребления памяти должен просто не замечать.

Здорово. А если еще вспомнить, что помимо памяти и процессора есть еще ряд немаловажных критериев и подставить их в вышеотквоченое, то спорить будет вобще не о чем.