OberonCore

Гиде SVN? StringsBase уже неактуален, у меня новый модуль завёлся - грузит тот же файл за ~860 msec

Круто. Положили бы его в форум, не всё ли равно...

Кажется он. Кстати, забавную штуку обнаружил: если несколько раз выполнить загрузку файла буз выгрузки модуля/освобождения памяти - время загрузки вырастает примерно в два раза (т.е. 860-1400-2100-...). Интересно, это глюк нового варианта или что?

Такое же было с StringsBase - я вроде о таком явлении говорил вскользь.

Прикрутил StringsXml к парсеру по-быстрому(обёртки - рулят). 4-хметровый загрузился за 2 секунды - отлично! При повторных загрузках время выросло до 5 секунд и больше не росло.

В ББ есть профилировщик - нужно его на систему натравить. Замедление связано скорее всего с особенностями выделения памяти. Ну и потом я там ещё в парсере оптимизации наметил, будет SVN - поправлю

Кстати, посмотрел что у меня за проц - Core2 Duo T7200 2 Ггц

Опишите примерно?

Тем временем, появился SVN-репозитарий. Я загрузил туда подсистемы Dom и Xmlcore. Логика SVN определяет правила разработки С ветками разработки я ещё пока сам не разобрался но тоже может пригодиться. Понеслась!!!

Посмотрел в код. Вроде бы этот доступ используется только в Parser. Причем доступ - последовательный, не произвольный.

Интересная задача, но счас времени нету совсем самому попробовать.

Иван, Пётр, у меня такое предложение:
- использовать считыватель для чтения строки вместо доступа к конкретному символу;
- строку хранить не как массив из кусков ARRAY StrSize OF CHAR, а как список из этих кусков (я бы взял фиксированный размер куска). При последовательном доступе чтение след. символа будет занимать фикс. время и, мне кажется, будет быстрее, чем GetChar.

- при убиении строки финализатор будет передавать её куски в список свободных кусков простым добавлением в начало, откуда их потом можно будет забирать (опять же с начала) при потребности в новом куске для расширения строки (обходимся без NEW).
Копить, напр, до опред. числа кусков.

Не удержался, переделал StringsXml вот в такую бодягу.Но чтой-то на ночь глядя не пошло. Память куда-то отжирается.

вложение удалено

Сначала думал на финализаторы - "It is not recommended to re-anchor an object in its finalizer...". Но re-anchor делается не на сам объект, а на его поле у которого нету финализатора. Так что может и пойдет такая штука...

Но убрал и финализаторы, и SYSTEM (вдруг косяк с адресами), все равно память отжирается

Я положил в SVN последний вариант Петра, пока без динамических строк.

Почему бы не залить наконец StringsXml в SVN?

У меня нормальный интернет с svnом на работе, а этот модуль - дома Завтра залью.

Добавил в SVN Strings\Mod\Xml. И свою версию Strings\Mod\Xml2. Вот хоть убей не пойму:

Если есть вывод Log.Char(r.ch) - память съедается. Нет вывода в лог - не съедается.

Ага, действительно.
Может, Лог каким-то образом умудряется записать данные в область, где лежат, или должны лежать строки?

Да врят ли проблема в логе...

Когда написал появились сомнения. Посмотрел декодированный вариант, ридер чуть получше. Однако если отказаться от переменного s.strSize и оставить константу равную степени двойки, GetChar укорачивается в два раза (нет обращения к полю и деление заменяется сдвигом).

Так что полезность моего варианта, если заработает, ещё под вопросом...

Основной затык скорости приходился на посимвольный набор строки, с посимвольным выделением памяти... Я в парсере делал временную затычку с длинным буфером(статическая строка 5-10 килосимволов) - на тех файлах, которые удавалось таким образом прочитать, выйгрыш в скорости был ощутимый.
Теперь строки вроде нормально работают без затычки даже. Может, поискать узкие места в самом алгоритме парсера/сканнера?

Когда я говорил про оптимизации - имел ввиду две вещи:

1. Создание пустых строк заменить на присваивание StringsXml.null. Меньше вызовов NEW и фрагментация памяти
2. Ввести процедуру StringsXml.Compare - избавимся от этого непонятного буфера в XmlcoreScanner.ScanContent и опять же выкинем NEW.

За сам алгоритм ничего сказать не могу - там, в отличие от строк, думать надо

Я ввёл переменную для возможности подстройки размеров буфера под конкретный файл. Можно ввести константы, но тогда нужно выбирать для них оптимальные значения

Про пустые строки: Сделал такое внутри DomStrings, только там используются пустые строки при инициализации пустых полей узлов. Особого прироста в скорости нету. Может, надо что-то глобально переделать...

Про непонятный буфер: он используется только в случае, если в тексте встречается комбинация символов "<$". Достаточно редкая комбинация, сейчас, при тестах она особо не влияет на скорость.