OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 05:03

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 44 ]  На страницу 1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Strings - средства работы со строками
СообщениеДобавлено: Пятница, 06 Июнь, 2008 19:04 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
(02.08.2011, модератор) ветка выделена отсюда: viewtopic.php?p=15935#p15935

Конец выделения: viewtopic.php?p=16238#p16238. На этом "участке" обсуждается задача разработки библиотечного модуля динамических строк, заточенного под потребности подсистемы Xmlcore. Итог: StringsXml (см. https://svn.oberoncore.ru/community/old ... k/Strings/)
=====

viewtopic.php?p=15935#p15935
Иван Горячев писал(а):
...Собственно вот (4 мб)


Попробовал пропустить этот файл через парсер, обнаружил дикие тормоза. Покопавшись обнаружил возможную причину тормозов - медленая работа с динамическими строками. Попробовал оптимизировать внутренние алгоритмы парсера, тестировал на различных больших файлах с длинными строками внутри, стало работать быстрее чем было, но всё равно медленно. 4-хметровый SVG так и не покорился. По тестам: XML-файл с максимальной глубиной ветвления элементов 3-4 уровня и достаточно длинными строками (размер файла ~320 кбайт) открывается за полминуты, а записывается на диск за 150 миллисекунд. При чтении используются Basics, потом все строки хранятся в виде обычного массива. При записи Basics не используется. Нужен хороший модуль по работе с динамическими строками.

(02.08.2011) модератор: размещено в коллекции: http://oberoncore.ru/bbcc/subs/strings/


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 06 Июнь, 2008 22:47 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Petryxa писал(а):
... Нужен хороший модуль по работе с динамическими строками.

Думаю, нужно сначала внимательно на алгоритмы посмотреть и попытаться квази-избавиться от динамических строк.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 07 Июнь, 2008 06:04 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Оно конечно можно, и нужно. Что я и сделал. Но по-моему, всеми оптимизациями работы с динамическими строками должен заниматься автор подсистемы для работы с динамическими строками. Мне воообще неохота возиться со строками: я тупо взял компонент, заюзал его, и теперь должен доработать напильником. То есть, мне проще сделать все полностью компоненты самому, и тогда я буду знать что к чему, буду иметь возможность оптимизировать и подправлять их работу.
*тут я немного ушёл от конкретного рассуждения про динамические строки, к рассуждению об использовании стороних компонент вообще.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 07 Июнь, 2008 20:24 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
По-моему, Info21 говорил про алгоритмы не в том модуле : )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 07 Июнь, 2008 20:42 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Valery Solovey писал(а):
По-моему, Info21 говорил про алгоритмы не в том модуле : )


Да я понял, про что он говорил. Он говорил про алгоритмы в модули Xmlcore, в которых идёт интенсивная работа с динамическими строками. С одной стороны, оно конечно верно, я оптимизировал(слегка) свой алгоритм, попутно нашёл пару багов, это всё хорошо. Но с другой стороны, оптимизировать работу с динамическими строками мог автор модуля "работа с динамическими строками", это ведь его детище.

ЗЫ. Лезть и править в чужой код мне очень не нравится и не хочется, делаю такое крайне редко.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 08 Июнь, 2008 15:41 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Petryxa писал(а):
4-хметровый SVG так и не покорился. По тестам: XML-файл с максимальной глубиной ветвления элементов 3-4 уровня и достаточно длинными строками (размер файла ~320 кбайт) открывается за полминуты, а записывается на диск за 150 миллисекунд. При чтении используются Basics, потом все строки хранятся в виде обычного массива. При записи Basics не используется. Нужен хороший модуль по работе с динамическими строками.


Я тут немного поиздевался над динамическими строками. Короче, этот 4-хметровый svg: 1422 msec - чтение, 2343 msec - запись по Timed execute, отжирает около 21 метра. Можно ускорить, но тогда память совсем неприлично расходуется. Графического редактора под рукой проверить нет, но Firefox открывает оба, причём отрисовывает немножко по-разному :?

А автора Basics нужно заставить вручную байты на компьютере персчитывать :evil:

Кстати, запись тоже была с косяком - доже строки.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 08 Июнь, 2008 17:32 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Иван Горячев писал(а):
Я тут немного поиздевался над динамическими строками.

Давайте погодим "издеваться" :) , дождёмся, пока появится репозиторий, а то я уже кое-что добавил к подсистемам, а тут пришлось разбираться с версиями. За модуль StringsBase спасибо, я только хотел свой начать воплощать. Планировал заюзать (System)Mem, там как раз есть работа с динамическими массивами и предвыделение памяти.

Иван Горячев писал(а):
1422 msec - чтение, 2343 msec - запись по Timed execute, отжирает около 21 метра.

Выполнил простой код, без записи даже:
Код:
t:=Services.Ticks();
doc:=XmlcoreCmds.LoadXMLDocument('Xmlcore/Rsrc/antarctica.svg');
StdLog.String('read ');StdLog.Int(Services.Ticks()-t);

Получилось(в среднем) 20 сек., если демка выполняется сразу после запуска среды, и 100 сек., если выполнить демку ещё раз, предварительно выгрузив демо-модуль. Может это из-за тормознутости моей системы (AthlonXP+ 2500 XP, 1024 RAM, WinXP SP2), или неизвестно из-за чего ещё...
Включив запись в файл, так и не дождался окончания...
Иван Горячев писал(а):
Графического редактора под рукой проверить нет, но Firefox открывает оба, причём отрисовывает немножко по-разному

Ну, я тут в IncScape демки всякие рисовал, потом через Xmlcore пропускал... Всё вроде одно и то же, и редактор не ругался... Размеры файлов меняются на несколько килобайт, но это может происходить из-за смены кодировки, или из-за добавления whitespaces всяких... По крайней мере, валидацию проходят все записанные в последнее время файлы. Валидность файлов проверяю просмотром готового xml-файла в Internet Explorer, он там структуру рисует, если всё верно, или указывает место ошибки.
Иван Горячев писал(а):
Кстати, запись тоже была с косяком - доже строки.

Да, похоже это как раз то, что я поправил.
Иван Горячев писал(а):
А автора Basics нужно заставить вручную байты на компьютере персчитывать
Ага, точно. Это ж надо умудриться, для добавления символа в строку заниматься её копированием в новую строку...
Код из BasicsDynStrings:
Код:
PROCEDURE AddRight (inoutString: DynString; IN str: ARRAY OF CHAR);
      (* str is added to content of string at the right side. *)
      VAR newString: POINTER TO ARRAY OF CHAR;
   BEGIN
      NEW (newString, LEN (inoutString.content$) + LEN (str$) + 1);
      newString^ := inoutString.content$ + str$;
      inoutString.content := newString
   END AddRight;

...и чуть ниже...
Код:
PROCEDURE (string: DynString) AddCharRight* (inChar: CHAR), NEW;
      (* inChar is added at the right side of the content of string. *)
      VAR str: ARRAY 2 OF CHAR;
         oldLength: INTEGER;
   BEGIN
      oldLength := LEN (string.content$);
      str[0] := inChar;
      str[1] := 0X;
      AddRight (string, str);

      (* Post: string.Length = oldString.Length + 1 *)
      Assert.PostStringValid (string.content);
      Assert.PostStringLenOk (LEN (string.content$) = oldLength + 1, string.content$, oldLength + 1)
   END AddCharRight;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 01:33 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Petryxa писал(а):
Давайте погодим "издеваться" :) , дождёмся, пока появится репозиторий, а то я уже кое-что добавил к подсистемам, а тут пришлось разбираться с версиями. За модуль StringsBase спасибо, я только хотел свой начать воплощать. Планировал заюзать (System)Mem, там как раз есть работа с динамическими массивами и предвыделение памяти.

Модуль откровенно "сырой" - за пол-часа на коленке. Если подходит - суйте его в репозиторий тоже, буду доводить.

Цитата:
Выполнил простой код, без записи даже:
Получилось(в среднем) 20 сек., если демка выполняется сразу после запуска среды, и 100 сек., если выполнить демку ещё раз, предварительно выгрузив демо-модуль. Может это из-за тормознутости моей системы (AthlonXP+ 2500 XP, 1024 RAM, WinXP SP2), или неизвестно из-за чего ещё...

Core2Duo (ноут, не помню сколько), 1024 мб. Гонял циклы "загрузка svg -> выгрузка демки" и "загрузка svg -> сохранение svg -> выгрузка демки" несколько раз, результаты не сильно отличаются от того что я указал.

Цитата:
Включив запись в файл, так и не дождался окончания...
...
Да, похоже это как раз то, что я поправил.

Если имеется ввиду DomStrings.Concat - то это как раз "косяк" :) У меня он тоже уходил в глубокую задумчивость.

Да, но для приближения по скорости к "промышленным" парсерам ещё работать и работать :)

Кстати, Вы используете ББ 1.5? В 1.6 модуля National нет, я из XmlcoreWriters его вырезал


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 09:03 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Цитата:
результаты не сильно отличаются от того что я указал.

Ну, видимо да, дело в процессоре и в версии ББ.
Цитата:
Если имеется ввиду DomStrings.Concat - то это как раз "косяк" :) У меня он тоже уходил в глубокую задумчивость.

Я делал так: убрал свои текущие подсистемы, распаковал подсистемы с вашими исправлениями, откомпилял, запустил. Результат известен. Так что, если вы поправили "косяк", то оно должно было работать.
Цитата:
Кстати, Вы используете ББ 1.5? В 1.6 модуля National нет, я из XmlcoreWriters его вырезал

Ага, ББ 1.5 и сервис пак последний. National - он конветрует ББ-шный "русский язык" в юникод, который потом конвертируется в UTF-8. Мне лично поддержка русского языка нужна. Нестыковочка-с.
Цитата:
но для приближения по скорости к "промышленным" парсерам ещё работать и работать

Думаю, правильнее сосредоточить силы на развитие функциональности.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 09:10 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Petryxa писал(а):
Я делал так: убрал свои текущие подсистемы, распаковал подсистемы с вашими исправлениями, откомпилял, запустил. Результат известен. Так что, если вы поправили "косяк", то оно должно было работать.

Странно. Ну подождём SVN

Цитата:
Ага, ББ 1.5 и сервис пак последний. National - он конветрует ББ-шный "русский язык" в юникод, который потом конвертируется в UTF-8. Мне лично поддержка русского языка нужна. Нестыковочка-с.

Там в SVNе много чего есть, в том числе и модуль Unicode с конвертилкой по кодовым таблицам. Так что всё пучком :)

Цитата:
Думаю, правильнее сосредоточить силы на развитие функциональности.

XSL, XPath и иже с ними?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 09:13 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Petryxa писал(а):
Давайте погодим "издеваться" :) , дождёмся, пока появится репозиторий, а то я уже кое-что добавил к подсистемам, а тут пришлось разбираться с версиями. За модуль StringsBase спасибо, я только хотел свой начать воплощать. Планировал заюзать (System)Mem, там как раз есть работа с динамическими массивами и предвыделение памяти.

1) Попробуйте динамические строки UtilExtStrings.
2) А нужны ли здесь отдельные динамические строки, когда каждая строка есть отдельный массив? По крайней мере при чтении xml, как я понимаю, дело идет с большим числом строк, размер которых не меняется (после прочтения). Может стоит думать о реализации массива строк? Например, как сделано чтение строковых ресурсов в ББ.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 09:27 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Евгений Темиргалеев писал(а):
1) Попробуйте динамические строки UtilExtStrings.

Не надо. Там строки основаны на деревьях, и на каждый символ приходится больше 20 байт. Нет, для XMLа требуется отдельный вид строк, заточенный под скорость наращивания и минимизацию расходов памяти.

Цитата:
2) А нужны ли здесь отдельные динамические строки, когда каждая строка есть отдельный массив? По крайней мере при чтении xml, как я понимаю, дело идет с большим числом строк, размер которых не меняется (после прочтения). Может стоит думать о реализации массива строк? Например, как сделано чтение строковых ресурсов в ББ.

Так проблема именно в чтении. Там динамика и используется. И, кстати, ещё как меняется. Зачем мы файл читаем? - чтобы поправить и сохранить


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 09:51 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Иван Горячев писал(а):
Не надо. Там строки основаны на деревьях, и на каждый символ приходится больше 20 байт.
Один символ :shock: Я думал куски строки в дереве стоят... В C++STL помню был какой-то контейнер, кажется rope, который использовал древесный метод хранения для работы с гиганскими строками... Хотя гигантские строки для xml не нужны, согласен.
Иван Горячев писал(а):
Так проблема именно в чтении. Там динамика и используется. И, кстати, ещё как меняется. Зачем мы файл читаем? - чтобы поправить и сохранить
Дык менять то будем после чтения. Если будем (чтобы показать туже svg-картинку - разве надо что-то менять?). И ведь не каждая строка меняется... Вот мне кажется, что нужно думать о специальном массиве строк. Это позволит лучше оптимизировать затраты памяти.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 09:54 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток
Евгений Темиргалеев писал(а):
Один символ :shock:

Код:
   Char = POINTER TO RECORD (Avl.Elem)
         c: CHAR;
      END;
      
      StdString = POINTER TO RECORD (String)
         chars: Avl.Tree;
      END;


Цитата:
Вот мне кажется, что нужно думать о специальном массиве строк. Это позволит лучше оптимизировать затраты памяти.


Ну и я про то же. Скорость добавления символов и минимум памяти


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 10:00 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Цитата:
Там в SVNе много чего есть, в том числе и модуль Unicode с конвертилкой по кодовым таблицам. Так что всё пучком :)

Доступа пока нет - а значит и модуля - нет.
Цитата:
XSL, XPath и иже с ними?

Ну, для начала хотя бы DTD добить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 10:03 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Уважаемый, Petryxa, а Вы не могли бы перечислить, какие операции со строками используется?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 10:13 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
    Добавление одного символа справа(BasicsDynStrings.AddCharRight)
    добавление строки справа(BasicsDynStrings.AddStringRight)
    доступ к конткретному символу(BasicsDynStrings.Char)
    выделение подстроки(BasicsDynStrings.PartAsString)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 10:27 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
И ещё один момент. Правильно ли предположение о том, что есть вспомогательные временные строки (1), которые используются при построении xml-дерева, и строки, которые собственно сидят в дереве (2)?

Какие операции применимы к строкам (1) (2) во время чтения xml, какие операции потребуются для (2) при последующем редактировании?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Июнь, 2008 12:59 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Начать надо с того, что "строка" в BasicsDynStrings - это не строка, а класс. И со Basics-строкой работа ведётся через методы, которые я указал ранее(там опечатка вкралась, это всё - методы DynString). В DOM-документе все строки представлены в самом простом виде - как POINTER TO ARRAY OF CHAR.
Соответственно, (1) это BasicsDynStrings.DynString, (2) - это POINTER TO ARRAY OF CHAR.
К (1) применимы методы BasicsDynStrings, к (2) - ну, методы, которые применимы к строкам в ББ. Извлечь собственно указтель на строку из (1) помогает метод String(), создать новый экземпляр (2) помогает простейшая процедура DomStrings.String(IN text : ARRAY OF CHAR) : POINTER TO ARRAY OF CHAR;

Редактирование (2) не предусмотрено. Предусмотрена установка значения какого либо строкового параметра узла(Node) документа через метод узла или его потомка.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 11 Июнь, 2008 14:48 

Зарегистрирован: Вторник, 29 Август, 2006 12:32
Сообщения: 2662
Откуда: Россия, Ярославль
Прикрутил модуль StringsBase через обёрточный модуль(чисто на всякий случай :) ) к Xmlcore. Результат: злополучный 4-хметровый SVG был прочитан в память за 20 секунд и записан за 0.7 секунд. Пример показателен тем, что в SVG длина строковых значений параметров может быть порядка 10000 знаков, тогда как узлов будет всего несколько десятков штук, что при посимвольном наборе строки может значительно влиять на время прочитывания xml-файла в целом.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 44 ]  На страницу 1, 2, 3  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB