Автор |
Тема: Оператор printstr (Прочитано 26429 раз) |
|
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 символов короче.
|
|
Зарегистрирован |
|
|
|
|
|