Автор |
Тема: Оператор printstr (Прочитано 26431 раз) |
|
box_vma
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 49
|
Добрый день!
Подскажите, может есть какой-нибудь способ оптимизации работы оператора printstr?
Ниже приведены тексты двух отчетных форм, в первой 1000 строк выводятся в файл, во второй на экран клиента.
Первая форма выполняется в течении 9 секунд, вторая мгновенно.
* тест 1
tb=[sf 0,99]; printstr tb+[ch 10]
ff=[dir 0]+'test'
\> file ff
for i=1 to 1000
ss='Строка '+[intsn i]+[ch 10]
printstr ss to file ff
endfor
te=[sf 0,99]; printstr te+[ch 10]
Результат работы формы:
Thu, 19 May 2016 08:14:17
Thu, 19 May 2016 08:14:26
* тест 2
tb=[sf 0,99]; printstr tb+[ch 10]
for i=1 to 1000
ss='Строка '+[intsn i]+[ch 10]
printstr ss
endfor
te=[sf 0,99]; printstr te+[ch 10]
Результат работы формы:
Thu, 19 May 2016 08:17:17
Строка 1
...
Строка 1000
Thu, 19 May 2016 08:17:17
Существуют ли способы ускорить вывод в файл?
Спасибо,
с уважением В. Антипин
|
|
 Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
Попробуйте на модном клиенте так:
ff=[dir0]+'TEST_MODKL'
for i=1 to 1000
ss='F:'+ff+'|Строка '+[intsn i]+[ch 10]
printstr ss
endfor
В задании имени файла, конечно, нужно учитывать, что этот файл создает сам клиент, а не сервер.
Времена создания файлов будут отличаться в зависимости от уровня файловых подсистем.
В частноси у меня получилось так:
Новая фоpма, pедактиpуйте ее
тест 1 - в файл сервер пишет
Thu, 19 May 2016 14:24:03
Thu, 19 May 2016 14:24:04
тест 2 - в отчетную форму сервер пишет
Thu, 19 May 2016 14:24:04
Строка 1
Строка 2
Строка 3
Строка 4
..............
..............
Строка 994
Строка 995
Строка 996
Строка 997
Строка 998
Строка 999
Строка 1000
Thu, 19 May 2016 14:24:04
тест 3 - в отчетную форму сервер пишет, а клиент переписывает
из отчетной формы в раб.каталог, который совпадает с клиентским.
Thu, 19 May 2016 14:24:04
Thu, 19 May 2016 14:24:04
|
| « Изменён в : 19.05.16 в 14:28:53 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
box_vma
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 49
|
Борис, спасибо за совет, но в моем случае клиент, к сожалению, не используется.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
Есть ещё самый простой способ - просто переименовать *.OUT
На модном клиенте - элементарно(CHANEL), а на вашем - не знаю, чем вы сейчас пользуетесь.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
Это небольшой анонс будущего обновления клиента по мотивам последних работ связаных с экспортом больших отчетов(более 3тыс. строк в таблицах) в Excel и последнего совета в этой ветке ПП.
//BK 20160613 - YYYYMMDD
Реализован автопереход к внешнему приложению при попытке отображения отчёта формы, ИСКЛЮЧИТЕЛЬНО в HTML-формате.
Условием такого перехода является наличие:
1. контекста <HTML> в первой позиции первой строки отчета;
2. строки с тегом <TITLE>, которым задаётся имя(в cp866-кодировке) файла, который и будет открыт внешним приложением, которое будет выбрано согласно текущей ассоциации по указанному расширению в этом имени;
При этом имя файла может быть задано полным, т.е. с указанием пути.
В общем случае, путь может быть произвольным. Рекомендуется указывать путь каталога обмена клиента.
В этом случае будет произведено простое переименование *.OUT в указанное имя в теге <TITLE>.
Пример задания имени может выглядеть так:
<TITLE>P:\AHMET\_2016_\AD\_ФБП_отчет.doc</TITLE>
При этом окно такой формы откроется, но загружаться не будет, и будет закрыто автоматически после запуска окна или вкладки внешнего приложения.
Никаких ограничений на объём. Возможно, внешние приложения быстрее "заткнутся" на объёмах. В последних опытах, браузеры открывают html гораздо быстрее, что, конечно, логично.
Напомним, что на сегодня, популярные Word и Excel открывают без проблем файлы содержащие HTML-теги, имеющие расширения .doc и .xls, соответственно.
Таким образом, настройщики могут отказаться от HTML-вывода во внесистемный файл и параллельности с выводом отчёта.
Т.е. теперь, форма, реализующая отчет с выгрузкой экспортного файла должна выполняться в двух режимах, первый - обычный вывод, второй - должен сгенерировать отчет исключительно в HTML-формате, об остальном позаботится clw32.
По-большому счёту это можно реализовать и на штатном клиенте, единственное, не удасться избежать загрузки в окно формы самого HTML-формата и на больших отчетах получить ограничение по количеству строк. Всем известно, что HTML не отличается компактностью и плотностью.
Советую всем альтернативным клиентам реализовать такой алгоритм, конечно, если такой или подобный ещё у вас не реализован.
|
| « Изменён в : 18.06.16 в 11:46:29 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 20.06.16 в 11:09:39, DANILOV wrote:
Конечно, спасибо за заботу, только здесь немного другая проблема обсуждается.
Прочтите, пожалйста, самое начало этой веточки.
|
|
Зарегистрирован |
|
|
|
DANILOV
Я люблю этот Форум!
Просмотреть Профиль |
Сообщений: 12
|
on 20.06.16 в 12:16:53, Boris, Kiev. wrote:
Конечно, спасибо за заботу, только здесь немного другая проблема обсуждается.
Прочтите, пожалйста, самое начало этой веточки.
|
|
Я так понял, что обсуждается вопрос медленного вывода данных в файл. Эта проблема была и у нас до корректировки регистра. После корректировки формы , где есть вывод в файл, стали работать значительно быстрее.
|
|
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
on 23.06.16 в 13:29:41, DANILOV wrote:| Я так понял, что обсуждается вопрос медленного вывода данных в файл. |
|
Действительно, здесь обсуждается этот вопрос. Но в указанной Вами ветке, скорее обсуждалась медленная скорость сетевого доступа к файлам каталога обмена (из-за введения Майкрософтом новых версий протокола smb).
С темой этой ветки больше перекликается давнее обсуждение здесь оператора printstr и целесообразности введения новых операторов вывода текста. Касаемо же оператора printstr, по моим наблюдениям, многое зависит от размера выводимых строк. Сравнивать, имхо, целесообразно тесты на вывод данным оператором статичных строк с одинаковым количеством символов.
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 23.06.16 в 15:32:42, mine-R wrote:
С темой этой ветки больше перекликается давнее обсуждение здесь оператора printstr и целесообразности введения новых операторов вывода текста.
|
|
Жаль конечно, что реально в этом направлении ничего не подправили.
Quote:
Касаемо же оператора printstr, по моим наблюдениям, многое зависит от размера выводимых строк. Сравнивать, имхо, целесообразно тесты на вывод данным оператором статичных строк с одинаковым количеством символов. |
|
Это ведь несложно проверить. Интересно, насколько подтвердится ваше предположение.
Последним своим большим сообщением хотел акцентировать на большой разности скоростей вывода в системный *.out и любой пользовательский файл и вариантах обхода этого узкого места нашей платформы.
|
|
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
on 23.06.16 в 20:13:21, Boris, Kiev. wrote:| Это ведь несложно проверить. Интересно, насколько подтвердится ваше предположение. |
|
Да собственно это было достаточно очевидно, но я действительно проверил. По алгоритму, схожему с представленным выше box_vma, но без нумерации, вывод тысячи строк из одного единственного символа, на разных машинах, отработал примерно в 10 раз быстрее вывода строк из 250 символов. Разумеется, это результат локальной версии. В сети, на самой медленной машине, максимум удалось получить разницу в секунду. Думаю, что узким местом мог стать cgi-шлюз, являющийся по своей сути консольным приложением. Но опять же, это мои предположения, от категоричных выводов воздержусь.
upd: Чтобы получить разницу в секунду в сети, нужно пускать форму 25-30 раз подряд. (Pentium-MMX  в реальной работе не используется). Хочу этим сказать, что иногда получающуюся разницу в секунду, вероятно даёт вовсе и не платформа.
Quote:| Последним своим большим сообщением хотел акцентировать на большой разности скоростей вывода в системный *.out и любой пользовательский файл и вариантах обхода этого узкого места нашей платформы. |
|
Эта мысль вскользь мелькнула уже в давнем обсуждении. Форма-1, выводящая в box *.in с нужным именем и запросом на запуск Формы-2, которая собственно достаточно быстро и производит в *.out эти самые html, xml, при особом желании даже rtf, и прочее, имеющее основой текстовый формат. Вы сделали это более удобным, передав часть рутинных функций Клиенту, избавив настройщиков от отслеживания out'а и переименований "вручную", если я правильно понял анонс.
|
| « Изменён в : 26.06.16 в 09:02:45 пользователем: mine-R » |
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
on 25.06.16 в 21:15:44, mine-R wrote:
Да собственно это было достаточно очевидно, но я действительно проверил.... отработал примерно в 10 раз быстрее вывода строк из 250 символов.
|
|
Вы меня заставили поупражняться.
Получил парадоксальный результат, а именно на 10тыс. строках вывод длинной строки занял на секунду меньше времени в счетчиках сервера.
тест 1 - в файл сервер пишет КОРОТКУЮ СТРОКУ SI=
1
--DO
Sun, 26 Jun 2016 09:39:33
--POSLE
Sun, 26 Jun 2016 09:39:41
тест 1 - в файл сервер пишет ДЛИННУЮ СТРОКУ SI=
111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111
--DO
Sun, 26 Jun 2016 09:39:41
--POSLE
Sun, 26 Jun 2016 09:39:48
"Такого быть не может!" и запустил профиллер:
-------------------------------
Вpеменной пpофиль фоpмы ZPR
Количество выполнений: для фоpм не запоминается.
На это количество выполнений потpебовалось 15042 мс = 100%
Распpеделение вpемени по стpокам исходного текста в относительных %, и мс:
~ ~│0001 * скорость вфвода в файл.
~ ~│0002 KS=10000
~ ~│0003 SI='1'
~ ~│0004 тест 1 - в файл сервер пишет КОРОТКУЮ СТРОКУ SI=
~ ~│0005
~ ~│0006 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~ ~│0007
~ ~│0008 --DO
~ ~│0009 tb=[sf 0,99]; printstr tb+[ch 10]
~ ~│0010 ff=[dir 0]+'test1'
~ ~│0011 \> file ff
~ 1│0012 for i=1 to KS
~ ~│0013 * ss='Строка '+[intsn i]+[ch 10]
0.2% 25│0014 ss=SI +[intsn i]+[ch 10]
######### 49.3% 7416│0015 printstr ss to file ff
~ 7│0016 endfor
~ ~│0017 --POSLE
~ ~│0018 te=[sf 0,99]; printstr te+[ch 10]
~ ~│0019
~ ~│0020 SI='11111111111111111111111111111111111111111111111111111111111111111111 111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111111111111111111111111111111111111111111111111111
~ ~│0021 тест 1 - в файл сервер пишет ДЛИННУЮ СТРОКУ SI=^^^^SI
~ ~│0022
~ ~│0023 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
~ ~│0024
~ ~│0025 --DO
~ ~│0026 tb=[sf 0,99]; printstr tb+[ch 10]
~ ~│0027 ff=[dir 0]+'test2'
~ ~│0028 \> file ff
~ 4│0029 for i=1 to KS
~ ~│0030 * ss='Строка '+[intsn i]+[ch 10]
0.1% 21│0031 ss=SI +[intsn i]+[ch 10]
########## 50.3% 7565│0032 printstr ss to file ff
~ 3│0033 endfor
~ ~│0034 --POSLE
~ ~│0035 te=[sf 0,99]; printstr te+[ch 10]
~ ~│0036 stop
------------------------------------
Всё встало на свои места, т.е. сервер тратит на вывод короткой и длинной строки практически одинаковое время, конечно, если 1% - это то, за что мы здесь боремся, то конечно, Вы правы.
Добавлю, что проблема, которую мы пытаемся уяснить касается ИСКЛЮЧИТЕЛЬНО особенности работы сервера по скорострельному выводу в системный *.out и тяжким выводом в пользовательский файл безотносительно параметров работы сети и прочего железа. Хотя о SSD упоминал. С SSD реальное время на моем железе снизилось в 10 раз и актуальность этой проблемы серьёзно снизилась, "але" 
|
|
Зарегистрирован |
|
|
|
Boris, Kiev.
Адепт ФБП с 1996г.
Просмотреть Профиль | E-мэйл
Сообщений: 875
|
Наш ПП "не любит" длинные сообщения.
on 25.06.16 в 21:15:44, mine-R wrote:
Вы сделали это более удобным, передав часть рутинных функций Клиенту, избавив настройщиков от отслеживания out'а и переименований "вручную", если я правильно понял анонс. |
|
Спасибо, поняли правильно, и добавлю, что, то время, которое клиент реально ожидает отчёт также зависит от скорости самого клиента по его выводу. Т.к. модный клиент в случае выполнения условий, о которых выше сказано, выходит из цикла разбора строк *.out, как правило в пределах первых 10 строк, независимо от объема самого *.out(а это могут быть десятки мегабайт на реальных задачах) , то и понятно, что время реакции клиента кардинально сокращается, практически =0, остаётся, только чистое время работы самого сервера над формой по выдаче *.out
И ещё оптимизация самого процесса заключается в том, что пользователь застрахован от холостых нагрузок на сервер в случае выполнения формы по выводу файла, предназначенного для импорта и собственного отказа его загрузки внешним приложением или банального обновления формы.
|
| « Изменён в : 26.06.16 в 11:15:30 пользователем: Boris, Kiev. » |
Зарегистрирован |
|
|
|
mine-R
compact & flexible rulezzz
Просмотреть Профиль |
Сообщений: 150
|
on 26.06.16 в 11:00:27, Boris, Kiev. wrote:Хотя о SSD упоминал. С SSD реальное время на моем железе снизилось в 10 раз и актуальность этой проблемы серьёзно снизилась, "але"
|
|
Добавлю, что если ОЗУ серверной машины измеряется минимум 3-4 гигабайтами, то в качестве бесплатной альтернативы SSD можно делать вывод файлов на 50-100 мегабайтный виртуальный RAM-диск. В случае наличия объёмных ответов Сервера в *.out, на таком диске можно разместить и box (но ни в коем случае не каталог базы знаний!).
И вдогонку ещё о printstr
По результатам профилирования, конструкция
printstr s to file ff
у меня выполняется на 1/4 медленнее, чем конструкция
^^s>>file ff
19873 мс против 13503 мс на 10000 строк. Хотя максимальная длина строки, выводимая конструкцией с форматными вставками, будет на 8-10 символов короче.
|
|
Зарегистрирован |
|
|
|
|
|
