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

Цитата:

---

Сообщение от jerri

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

---

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

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

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

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

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

Цитата:

---

Сообщение от Vitamin

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

---

нет, с чего бы

Цитата:

---

Сообщение от Vitamin

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

---

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

Цитата:

---

Сообщение от Vitamin

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

---

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

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

Цитата:

---

Сообщение от jerri

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

---

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

Цитата:

---

Сообщение от Vitamin

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

---

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

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

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

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

Цитата:

---

Сообщение от esl

нет, с чего бы

---

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

Цитата:

---

Сообщение от esl

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

---

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

Цитата:

---

Сообщение от esl

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

---

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

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

Цитата:

---

Сообщение от vinxru

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

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

---

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

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

Цитата:

---

Сообщение от vinxru

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

---

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

Цитата:

---

Сообщение от Vitamin

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

---

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

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

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

Цитата:

---

Сообщение от esl

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

---

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

Цитата:

---

Сообщение от esl

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

---

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

Цитата:

---

Сообщение от Vitamin

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

---

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

Цитата:

---

Сообщение от Vitamin

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

---

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

Цитата:

---

Сообщение от esl

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

---

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

Цитата:

---

Сообщение от esl

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

---

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