Финансы без пpоблем: Пеpеговоpный Пункт II (http://hdru.com/cgi-bin/pp2/YaBB.cgi)
>> Пpедложения по усовеpшенствованию, сообщения об ошибках >> Оператор printstr
(Message started by: box_vma на 19.05.16 в 08:33:30)

Заголовок: Оператор printstr
Прислано пользователем box_vma на 19.05.16 в 08:33:30
Добрый день!

Подскажите, может есть какой-нибудь способ оптимизации работы оператора 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


Существуют ли способы ускорить вывод в файл?

Спасибо,
с уважением В. Антипин

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 19.05.16 в 14:10:45
Попробуйте на модном клиенте так:
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

Заголовок: Re: Оператор printstr
Прислано пользователем box_vma на 19.05.16 в 14:36:49
Борис, спасибо за совет, но в моем случае клиент, к сожалению, не используется.

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 19.05.16 в 14:42:00
Судя по 9 секундам, Вам надо бы уже перейти на SSD или просить СЕРВЕР править вывод в файл.

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 19.05.16 в 15:04:29
Есть ещё самый простой способ - просто переименовать *.OUT
На модном клиенте - элементарно(CHANEL), а на вашем - не знаю, чем вы сейчас пользуетесь.

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 18.06.16 в 07:11:20
Это небольшой анонс будущего обновления клиента по мотивам последних работ связаных с экспортом больших отчетов(более 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 не отличается компактностью и плотностью.


     Советую всем альтернативным клиентам реализовать такой алгоритм, конечно, если такой или подобный ещё у вас не реализован.

Заголовок: Re: Оператор printstr
Прислано пользователем DANILOV на 20.06.16 в 11:09:39
Если у Вас W7 то помогает изменение  в регистре. В этой теме  http://hdru.com/cgi-bin/pp2/YaBB.cgi?board=errors;action=display;num=1349332350;start=15 Вы уже поднимали подобный вопрос, но нашли что торможение связано с включением режима logmode.
А сделали Вы изменения в регистре ?

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 20.06.16 в 12:16:53

on 06/20/16 в 11:09:39, DANILOV wrote:
Если у Вас W7 то помогает изменение  в регистре. В этой теме  http://hdru.com/cgi-bin/pp2/YaBB.cgi?board=errors;action=display;num=1349332350;start=15 Вы уже поднимали подобный вопрос, но нашли что торможение связано с включением режима logmode.
А сделали Вы изменения в регистре ?


Конечно, спасибо за заботу, только здесь немного другая проблема обсуждается.
Прочтите, пожалйста, самое начало этой веточки.

Заголовок: Re: Оператор printstr
Прислано пользователем DANILOV на 23.06.16 в 13:29:41

on 06/20/16 в 12:16:53, Boris, Kiev. wrote:
Конечно, спасибо за заботу, только здесь немного другая проблема обсуждается.
Прочтите, пожалйста, самое начало этой веточки.

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

Заголовок: Re: Оператор printstr
Прислано пользователем mine-R на 23.06.16 в 15:32:42

on 06/23/16 в 13:29:41, DANILOV wrote:
Я так понял, что обсуждается вопрос медленного вывода данных в файл.

Действительно, здесь обсуждается этот вопрос. Но в указанной Вами ветке, скорее обсуждалась медленная скорость сетевого доступа к файлам каталога обмена  (из-за введения Майкрософтом новых версий протокола smb).

С темой этой ветки больше перекликается давнее обсуждение здесь (http://hdru.com/cgi-bin/pp2/YaBB.cgi?board=errors;action=display;num=1211354148) оператора printstr и целесообразности введения новых операторов вывода текста. Касаемо же оператора printstr, по моим наблюдениям, многое зависит от размера выводимых строк. Сравнивать, имхо, целесообразно тесты на вывод данным оператором статичных строк с одинаковым количеством символов.

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 23.06.16 в 20:13:21

on 06/23/16 в 15:32:42, mine-R wrote:
С темой этой ветки больше перекликается давнее обсуждение здесь (http://hdru.com/cgi-bin/pp2/YaBB.cgi?board=errors;action=display;num=1211354148) оператора printstr и целесообразности введения новых операторов вывода текста.

Жаль конечно, что реально в этом направлении ничего не подправили.

Quote:
Касаемо же оператора printstr, по моим наблюдениям, многое зависит от размера выводимых строк. Сравнивать, имхо, целесообразно тесты на вывод данным оператором статичных строк с одинаковым количеством символов.

Это ведь несложно проверить. Интересно, насколько подтвердится ваше предположение.

Последним своим большим сообщением хотел акцентировать на большой разности скоростей вывода в системный *.out и любой пользовательский файл и вариантах обхода этого узкого места нашей платформы.

Заголовок: Re: Оператор printstr
Прислано пользователем mine-R на 25.06.16 в 21:15:44

on 06/23/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'а и переименований "вручную", если я правильно понял анонс.

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 26.06.16 в 11:00:27

on 06/25/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=

1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

--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окам исходного текста в относительных %, и мс:

                        ~        ~&#9474;0001 * скорость вфвода в файл.
                        ~        ~&#9474;0002         KS=10000
                        ~        ~&#9474;0003 SI='1'
                        ~        ~&#9474;0004   тест 1 - в файл сервер пишет КОРОТКУЮ СТРОКУ SI=
                        ~        ~&#9474;0005
                        ~        ~&#9474;0006 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        ~        ~&#9474;0007
                        ~        ~&#9474;0008 --DO
                        ~        ~&#9474;0009 tb=[sf 0,99]; printstr tb+[ch 10]
                        ~        ~&#9474;0010 ff=[dir 0]+'test1'
                        ~        ~&#9474;0011 \> file ff
                        ~        1&#9474;0012 for i=1 to KS
                        ~        ~&#9474;0013 *   ss='Строка '+[intsn i]+[ch 10]
                     0.2%       25&#9474;0014    ss=SI        +[intsn i]+[ch 10]
          ######### 49.3%     7416&#9474;0015    printstr ss to file ff
                        ~        7&#9474;0016 endfor
                        ~        ~&#9474;0017 --POSLE
                        ~        ~&#9474;0018 te=[sf 0,99]; printstr te+[ch 10]
                        ~        ~&#9474;0019
                        ~        ~&#9474;0020 SI='111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
                        ~        ~&#9474;0021   тест 1 - в файл сервер пишет ДЛИННУЮ СТРОКУ SI=^^^^SI
                        ~        ~&#9474;0022
                        ~        ~&#9474;0023 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        ~        ~&#9474;0024
                        ~        ~&#9474;0025 --DO
                        ~        ~&#9474;0026 tb=[sf 0,99]; printstr tb+[ch 10]
                        ~        ~&#9474;0027 ff=[dir 0]+'test2'
                        ~        ~&#9474;0028 \> file ff
                        ~        4&#9474;0029 for i=1 to KS
                        ~        ~&#9474;0030 *   ss='Строка '+[intsn i]+[ch 10]
                     0.1%       21&#9474;0031    ss=SI        +[intsn i]+[ch 10]
         ########## 50.3%     7565&#9474;0032    printstr ss to file ff
                        ~        3&#9474;0033 endfor
                        ~        ~&#9474;0034 --POSLE
                        ~        ~&#9474;0035 te=[sf 0,99]; printstr te+[ch 10]
                        ~        ~&#9474;0036 stop

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

Добавлю, что проблема, которую мы пытаемся уяснить касается ИСКЛЮЧИТЕЛЬНО особенности работы сервера по скорострельному выводу в системный *.out и тяжким выводом в пользовательский файл безотносительно параметров работы сети и прочего железа. Хотя о SSD упоминал. С SSD реальное время на моем железе снизилось в 10 раз и актуальность этой проблемы серьёзно снизилась, "але"  ;)

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 26.06.16 в 11:06:57
Наш ПП "не любит" длинные сообщения.


on 06/25/16 в 21:15:44, mine-R wrote:
Вы сделали это более удобным, передав часть рутинных функций Клиенту, избавив настройщиков от отслеживания out'а и переименований "вручную", если я правильно понял анонс.


Спасибо, поняли правильно, и добавлю, что, то время, которое клиент реально ожидает отчёт также зависит от скорости самого клиента по его выводу. Т.к. модный клиент в случае выполнения условий, о которых выше сказано, выходит из цикла разбора строк *.out, как правило в пределах первых 10 строк, независимо от объема самого *.out(а это могут быть десятки мегабайт на реальных задачах) , то и понятно, что время реакции клиента кардинально сокращается, практически =0, остаётся, только чистое время работы самого сервера над формой по выдаче *.out
И ещё оптимизация самого процесса заключается в том, что пользователь застрахован от холостых нагрузок на сервер в случае выполнения формы по выводу файла, предназначенного для импорта и собственного отказа его загрузки внешним приложением или банального обновления формы.

Заголовок: Re: Оператор printstr
Прислано пользователем mine-R на 26.06.16 в 12:23:39

on 06/26/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 символов короче.

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 27.06.16 в 17:20:51

on 06/26/16 в 12:23:39, mine-R wrote:
виртуальный RAM-диск.


Да, это фишечка есть. Интересно, у кого из нас, и насколько широко применяется?
Лично, до сих пор, "торможу" с этим.


Quote:
И вдогонку ещё о printstr

По результатам профилирования, конструкция

printstr s to file ff

у меня выполняется на 1/4 медленнее, чем конструкция

^^s>>file ff

Да!!!. всё так. Помню, что даже была и есть п.п. выводящая строку с помощью  ">>" через кучу "if" от длины этой строки. На эти "if"ы уходит мизер по сравению с printstr. Помню, что обсуждали по этому поводу с Аркадием вычисляемый goto, но потом отказались, т.к. лобовой алгоритм давал приемлемые результаты. Да, компилляторы существенно поумнели. Для меня - тогда осталось загадкой, что лобовой алгоритм показал себя быстрее чем более продвинутый(с последовательным делением диапазона).

Заголовок: Re: Оператор printstr
Прислано пользователем mine-R на 01.07.16 в 17:23:42

on 06/27/16 в 17:20:51, Boris, Kiev. wrote:
Интересно, у кого из нас, и насколько широко применяется?

Думаю, очень нешироко  :) Ибо операционная система, достаточно часто доходит в своей энтропии до точки максимума, а при полной переустановке такие прибомбасики - первое о чём благополучно забывается.


Quote:
Да!!!. всё так. Помню, что даже была и есть п.п. выводящая строку с помощью  ">>" через кучу "if" от длины этой строки. На эти "if"ы уходит мизер по сравению с printstr. Помню, что обсуждали по этому поводу с Аркадием вычисляемый goto, но потом отказались, т.к. лобовой алгоритм давал приемлемые результаты. Да, компилляторы существенно поумнели. Для меня - тогда осталось загадкой, что лобовой алгоритм показал себя быстрее чем более продвинутый(с последовательным делением диапазона).


Однако в сравнении с выводом в .out конструкция с '>>' тоже прилично меркнет. Будет здорово, если для объёмных форм, реализация через вывод в out,  станет приоритетной не только для модифицированного клиента, но и для других клиентских разработок.

Заголовок: Re: Оператор printstr
Прислано пользователем Boris, Kiev. на 02.07.16 в 16:26:41
Обычно, перед публикацией здесь версии мод.клиента, все новшества обкатываются на реальных базах не менее 6мес, но «раз пошла такая пьянка», то милости просим, можете реально потестить модифицированного клиента на предмет работы с большими и маленькими <HTML> *.OUT(ами).

http://hdru.com/russian/Clw32_160618.zip


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

Напомню, что мод.клиент ставится без оплаты(10у.е./год) до конца календарного года, в котором принимается решение попробовать его, а  частные лица и предприятия, работающие на двухпользовательских серверах, пользуют и будут пользовать модифицированные версии клиента «бездвоздмездно».
:o :)

Заголовок: Re: Оператор printstr
Прислано пользователем mine-R на 02.07.16 в 18:51:44

on 07/02/16 в 16:26:41, Boris, Kiev. wrote:
...потестить модифицированного клиента на предмет работы с большими и маленькими <HTML> *.OUT(ами).

Потестил, подтверждаю - механизм в выводом в *.out даёт реактивную скорость :)

10000 строк по 255 символов - мгновенно запускается ассоциированное приложение.

100000 строк по 255  (выходной файл около 24Mb) - на моей машине в пределах 3 сек.



Powered by YaBB 1 Gold - SP 1.3.2!
Forum software copyright й 2000-2004 Yet another Bulletin Board