Выдление памяти (+)

Либо вы не знаете зачем нужны функции *alloc, либо нифига не понятно мысль разложена...

Динамически выделять память. В Си, С++?

А выделять кусками идея в голову не приходила?

язык С
кусками это конешно хорошо
только много нюансов
к примеру есть шаблон
bla bla <##need_replace> bla bla
парсер находит тэг, находит замену этому тэгу
размер замены опять же может быть 100 или 10000 байт
и как мне поступать в данной ситуации ?
выделить буфер размером текущий + замена ?
тогда всплывают 2 проблемы, 1 тэгов тысячи в сравнительно
небольшом шаблоне, постоянные малоки как мне кажется
повлияют на производительность, 2 придется постоянно копировать
из буфера в буфер постоянно растущий результат,
в текущей реализации парсинг линеен и одно проходен
т.е. выделяется большой буфер и туда собирается все за один проход
по итогу будет сильное падение производительности
что НЕДОПУСТИМО
разъясните, возможно я неправильно понял идею...

> в текущей реализации парсинг линеен и одно проходен
> т.е. выделяется большой буфер и туда собирается все за один проход
>

Ну так это же замечательно! В смысле однопроходность.
Нафига тебе писать результат в память? Раз уж результат у тебя может
достигать мегаразмеров то пиши его просто в файл, и ничего выделять не
придется. Делай анонимный временный файл и колбась туда. Если захочешь
- потом прочитаешь обратно целиком в память. Или будешь результат
по частям обрабатывать, в зависимости от размеров результата.
Или пиши в pipe или FIFO а вторым процессом/тредом обрабатывай
результат.

Альтернатовно, если пишешь на C++ то можешь поэкспериментировать:
пиши в ostream, который создаешь или как file stream или как string
stream. Может memory management для string stream тебя устроит...
а не устроит, переключишься на file stream.

Используй списочное представление строк (как в Хаскелле), будет тебе тогда щастя.

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

2 e2fsck
>Используй списочное представление строк (как в Хаскелле),
>будет тебе тогда щастя.

признаться, Хаскелль в глаза не видел
можно пояснить идею ?
как мне смутно кажется из формулировки суть
делать связанный список на элементы строки ?

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

Просто проверь, напиши программу, которая берет 100 метров и ничего не делает, и запусти команду free до и во время работы этой программы.

В этом, конечно, есть подводный камень, см. proc, overcommit_memory.

Всё очень просто - строка представляется как однонаправленный список символов. Оверхед по памяти - таки да, будет, производительность на этой конкретной задаче - будет сильно выше, чем для обычных ASCIIZ-строк.

Как компромиссный вариан ещё можно ASCIID использовать.