Семантика SHORT(x) в Компонентном Паскале

[trurl]

То есть по факту, большие файлы в ББ редактировать нельзя.

Странно, я для эксперимента открывал файл в 600М на компьютере с 512M ОЗУ. И вполне редактируется. Только вот сохранять долго, да.

[valexey_u]

То есть по факту, большие файлы в ББ редактировать нельзя.

Странно, я для эксперимента открывал файл в 600М на компьютере с 512M ОЗУ. И вполне редактируется. Только вот сохранять долго, да.

Видимо сильно зависит от содержимого, и, возможно, редакции/версии ББ.

[valexey_u]

То есть по факту, большие файлы в ББ редактировать нельзя.

Странно, я для эксперимента открывал файл в 600М на компьютере с 512M ОЗУ. И вполне редактируется. Только вот сохранять долго, да.

Видимо сильно зависит от содержимого, и, возможно, редакции/версии ББ.

Проверил на школьной сборке (это вроде бы 1.5) - то же самое.

[Geniepro]

То есть по факту, большие файлы в ББ редактировать нельзя.

Странно, я для эксперимента открывал файл в 600М на компьютере с 512M ОЗУ. И вполне редактируется. Только вот сохранять долго, да.

Возможно там этот документ поместился в виртуальную память, которая была больше чем 512М...

[ilovb]

Спасибо, valexey.
Я в очередной раз убедился что текстовая подсистема BB сделана хуже некуда.

Проверил Oberon V4
Открывает этот файл мгновенно. Потребление памяти 800 кб.

[valexey_u]

То есть по факту, большие файлы в ББ редактировать нельзя.

Странно, я для эксперимента открывал файл в 600М на компьютере с 512M ОЗУ. И вполне редактируется. Только вот сохранять долго, да.

Кажется я немного локализовал проблему: если создать большой текстовый файл (просто txt) в ASCII, то ББ его отлично открывает, и при этом потребление памяти не растет. Только что создал в фаре и открыл в ББ текстовый файл размером 177 Мб. Работает отлично. Не тормозит ни в каком месте (только открывал долго), если строки там не слишком длинные.

А вот если мы имеем ББ-документ большой, то все, амба. Жрет память и тормозит при листании. То есть со своими документами ББ работает хуже чем с txt. И свои документы он полностью засасывает в ОЗУ (видимо аля DOMа строит). Следовательно что? Следовательно свои документы можно было не мудря с кодировкой просто сжимать Хаффманом, если жалко места, а если не жалко, то хранить текст просто в ucs-2.

[valexey_u]

Спасибо, valexey.
Я в очередной раз убедился что текстовая подсистема BB сделана хуже некуда.

Проверил Oberon V4
Открывает этот файл мгновенно. Потребление памяти 800 кб.

См. мое сообщение выше. Если он у тебя открывает txt'шник, то это одно, если он открывает собственный составной документ где есть только этот текст - это другое.

[ilovb]

Проверил. Ничего не изменилось 

[ilovb]

Потребление памяти 800 кб.

Вру. Эти 800 кб. уходят мод загружаемые модули текстовой подсистемы при первом вызове Edit.Open

А под наш файлик выделяется примерно 12 кб. Т.е. как я и думал в памяти только то что на экране.
Только вот в BB это не так. Но там возможно файл мапится в память...

[Kemet]

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

[Илья Ермаков]

Стоп-стоп, господа, а вы сохранили этот документ в ODC, прежде чем открывать и что-то мерять?

Иначе он открывается через конвертер, порождается новый TextModel в памяти.

-- Пардон, прочёл выше. Странно.

[Илья Ермаков]

Но в итоге надо различать уровень TextModel и уже собственно отображения на экране.
Тормозит, скорее всего, не TextModel, который захреначен с расчётом на частичную подгрузку.
А уже выше в Views или Setters какой-нибудь конкретный алгоритм, сделанный "по быстрому" и "имеющий" текст целиком.

[igor]

Секреты компилятора

Эта статья написана мной 
Правда, указывать сей факт на Оберонкоре не сочли нужным...

Рад сообщить, что благодаря помощи Ильи Ермакова и при его непосредственном участии недоразумение с авторством статьи на Оберонкоре было устранено 

[igor]

Причины ошибки имели технический характер.

[DddIzer]

Причины ошибки имели технический характер.

Возможно... но не в целях разжигания междусобоя, но справедливости  ради..
 
обратите внимание на

"
Автор разделов «Опции компилятора» и «Маркер конца списка компиляции»: Лоскутов И.В.

Автор*: Горячев И.Н. Правки: Ермаков. И.Е.
"

вы всего  лишь "Автор разделов"  а  истинные авторы  ниже