Как организовать память для текстового редактора?

[esl]

Для чего?
Зачем на машине с 16к свободной памяти редактировать тексты больше чем 16 к?

в случае если редактор ТОЛЬКО для конкретной машины/случая - може и не стоит
но MIM был (и использовался для работы с БОЛЬШИМИ текстами)
на Ямахе/Корвете/УКНЦ/СМхх
у нас преподы набирали методички в нем, и очень ценили что есть ОДИН файл а не кучка.

хотя это вопрос привычки конечно

в том-же мим очень не привычная для большинства схема копирования/вставки, отдельные буфера для "символов"/"строк"/"кадратных блоков"

при этом уже тогда (1988 как минимум)
было Undo/Redo
Квадратные блоки
"бесконечный" текст
"псевдо директории"

[jerri]

вопрос в том
зачем сейчас писать такой редактор?
сфера применения?

[esl]

Ага. Все одинаково тормозит

нет, с чего бы

Что такое локальное редактирование и где оно медленное?

пример(только что открыл на корвете редактор E, там оказалась обычная вставка в текст со сдвигом)
открываем большой текст (~30k, почти вся память свободная у редактора)
в начале текста добавляем строку
пока редактируем ее - все быстро и хорошо
как только выходим из строки (например вниз)
сразу ЗАМЕТНАЯ пауза на копирование хвоста текста

Ну да. В предлагаемой схеме перемещение по тексту будет стоить. В обычных редакторах- не стОит (тупо поиск следующего/предыдущего перевода строки).

так прикол в том что в обычной жизни большие копирования будут только в местах где пользователь их нормально воспринимает (типа переход в другой конец текста)
зато при локальном редактировании (в пределах экрана) паузы нет вообще
а при PgUp/Dn она минимальна но тоже вполне ожидаема пользователем)

---------- Post added at 10:21 ---------- Previous post was at 10:19 ----------

вопрос в том
зачем сейчас писать такой редактор?
сфера применения?

как в том анекдоте, ну во первых это красиво
писать сейчас что угодно для тех компов - чистый фан
а вариант - не более чем альтернатива плоскому тексту

[vinxru]

Что такое локальное редактирование и где оно медленное?

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

Медленно будет, если мы каждую строку разместим в динамической куче. При этом 50% ОЗУ из из фрагментации может оказаться недоступным, а при увеличении строки придется выделать новый кусок из кучи. А это долго по факту. Это основная причина тормозов Java/.NET на современных компах, не то что 8080

---------- Post added at 10:25 ---------- Previous post was at 10:22 ----------

Причем, этот способ можно считать вообще бестормозным. Ибо скорость отрисовки целого экрана будет меньше, чем скорость копирования 30 Кб текста в ОЗУ.

[Vitamin]

нет, с чего бы

Потому что при навигации по тексту придется перебрасывать блоки памяти из начала в конец.

пример(только что открыл на корвете редактор E, там оказалась обычная вставка в текст со сдвигом)
открываем большой текст (~30k, почти вся память свободная у редактора)
в начале текста добавляем строку
пока редактируем ее - все быстро и хорошо
как только выходим из строки (например вниз)
сразу ЗАМЕТНАЯ пауза на копирование хвоста текста

Сделай то же самое на acedit. Текст можешь 64к сделать.

так прикол в том что в обычной жизни большие копирования будут только в местах где пользователь их нормально воспринимает (типа переход в другой конец текста)

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

---------- Post added at 11:30 ---------- Previous post was at 11:26 ----------

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

Медленно будет, если мы каждую строку разместим в динамической куче. При этом 50% ОЗУ из из фрагментации может оказаться недоступным, а при увеличении строки придется выделать новый кусок из кучи. А это долго по факту. Это основная причина тормозов Java/.NET на современных компах, не то что 8080

А разумно подходить не пробовал к вопросу? Или только как в рекламе "опустим газету в серную кислоту, а журнал в дистиллированную воду".

Назови хоть один plain текстовый редактор, в котором используется фрагментарное хранение текста. Желательно на тормозном Java/.NET

[ZEK]

Это основная причина тормозов Java/.NET

наоборот в .net/java память в куче выделяется мгновенно, там же сборщик дефрагментирует

[esl]

Назови хоть один plain текстовый редактор, в котором используется фрагментарное хранение текста. Желательно на тормозном Java/.NET

сейчас (когда много памяти) этого делать нет вообще смысла
дешевле построить связные списки
а тут речь в борьбе за каждый такт

кстати, про скорость, посчитал тут
на 8080 ldir одного байта - 48 тактов
и для корвета получаем время в фреймах
>>> 16к*1024*48/50000
15
>>> 30к*1024*48/50000
29
30 фреймов это почти пол секунды, уже ОЧЕНЬ заметно

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

[Vitamin]

сейчас (когда много памяти) этого делать нет вообще смысла
дешевле построить связные списки

Вот я и говорю- назови plain текстовый редактор на Java/.NET, где используется хранение редактируемого текста в виде связных списков.

30 фреймов это почти пол секунды, уже ОЧЕНЬ заметно

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

[esl]

Вот я и говорю- назови plain текстовый редактор на Java/.NET, где используется хранение редактируемого текста в виде связных списков.

я думаю что основная масса plain редакторов просто вызывает метод "редактируй мне этот буфер" и не парится

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

фигасе, да такая схема будет в РАЗЫ сложнее любых буферов
тем более что как я понимаю на целевом компе (специалист) вообще нет прерываний

[Vitamin]

я думаю что основная масса plain редакторов просто вызывает метод "редактируй мне этот буфер" и не парится

Ну и как работает редактирование-то?

фигасе, да такая схема будет в РАЗЫ сложнее любых буферов
тем более что как я понимаю на целевом компе (специалист) вообще нет прерываний

Твоя схема тоже сложнее, нежели редактирование сплошного куска. Всему своя цена. Разве на 8080 нет прерываний?