Уважаемые, возник вопрос с архитектуре хранения данных.
Как бы оптимально это сделать в текстовом редакторе с возможностью highlighting-a.

Пока насчитал два приемлимых варианта(для ANSI) текста:
1) Выделять буффер который будет в два раза больше текста плюс ещё небольшое пространство для возможности добавление (так называемый gap)
Этот gap будет перемещаться по буфферу и в него будут записываться вновь поступивший текст. При скушивание всего gap-a — реаллокация.
На каждый символ — 2 байта ( 1 байт для символа 1 для индекса его стиля).
Таблица стилей.
Плюс реаллокируемый массив с позициями начала строк в буффере.

За основу взят текст статьи http://www.cs.cmu.edu/~wjh/papers/byte.html и исходники текстового редактора http://scintilla.org/

2) Делать двусвязный список, узел каждого хранит начало строки соответствующей и указатель на начало списка в котором приписываются стили к тексту. Узел такого списка хранит индекс стиля и смещение от предыдущео стиля.
Строки можно тоже с gap сделать.

3) ...

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

Недостатки второго: Огромное количество мелких маллоков(реаллоков) особенно в при загрузке текста. Хотя кушать при большом количестве ссылок будет тоже порядочно.
Преимущества: Удобная запись в файл (построчная). Очень быстрое добавление/удаление строк. Никакого пересчёта позиций на строки


Пробовал облегчённую версию scintilla на 16mb файле с 240000 строками. Кушает чуть больше 40мб. Но невозможно работать еле ворочается.
На реплейсе зверском — вообще умерла.

Довольно неплохо справляется с такими кусками компонент для редактирования текста в Visual Studio. Может кто догадывается об его архитектуре? Вот только кушает он тоже подобно scintilla. Но скорость работы много быстрее.

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

Думаю выделить хеш массив для ключевых слов, чтобы лишних ссылок в стилях небыло, на больших файлах будет здоровская экономия.

Может завести поток какой, который будет постепенно добавлять во второй вариант строки и с синхронизировать. Можно будет параллельно работать.

Есть ли у кого идеи? варианты? советы?
Заранее примногоблагодарен.

Синтаксис для хайлайтинга что то близкоподобное к с++.
Всё это дело будет собираться без stl, boost, loki и им подобрых библиотек. Pure c++.