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

[Vitamin]

Vitamin, Редактирование в произвольном месте. не?

Самый тяжелый случай в плане переброса памяти- редактирование в начале большого текста.

[Advertiser]

[esl]

Самый тяжелый случай в плане переброса памяти- редактирование в начале большого текста.

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

[Vitamin]

для описываемой выше схемы - это вообще не играет роли где редактировать

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

локальное редактирование - всегда быстрое

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

а вот перемещение по тексту уже стоит, и тем больше нм дальше перемещение

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

[esl]

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

нет, с чего бы

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

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

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

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

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

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

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

[jerri]

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

[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

[esl]

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

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

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

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

[ZEK]

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

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

[Vitamin]

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

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

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

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