|
||||
Заголовок: Оператор 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:
Конечно, спасибо за заботу, только здесь немного другая проблема обсуждается. Прочтите, пожалйста, самое начало этой веточки. |
||||
Заголовок: 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:
Жаль конечно, что реально в этом направлении ничего не подправили. Quote:
Это ведь несложно проверить. Интересно, насколько подтвердится ваше предположение. Последним своим большим сообщением хотел акцентировать на большой разности скоростей вывода в системный *.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:
Эта мысль вскользь мелькнула уже в давнем обсуждении. Форма-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тыс. строках вывод длинной строки занял на секунду меньше времени в счетчиках сервера. тест 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окам исходного текста в относительных %, и мс: ~ ~│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='111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111 ~ ~│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 раз и актуальность этой проблемы серьёзно снизилась, "але" ;) |
||||
Заголовок: Re: Оператор printstr Прислано пользователем Boris, Kiev. на 26.06.16 в 11:06:57 Наш ПП "не любит" длинные сообщения. on 06/25/16 в 21:15:44, mine-R wrote:
Спасибо, поняли правильно, и добавлю, что, то время, которое клиент реально ожидает отчёт также зависит от скорости самого клиента по его выводу. Т.к. модный клиент в случае выполнения условий, о которых выше сказано, выходит из цикла разбора строк *.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:
Добавлю, что если ОЗУ серверной машины измеряется минимум 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:
Да, это фишечка есть. Интересно, у кого из нас, и насколько широко применяется? Лично, до сих пор, "торможу" с этим. Quote:
Да!!!. всё так. Помню, что даже была и есть п.п. выводящая строку с помощью ">>" через кучу "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:
Однако в сравнении с выводом в .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:
Потестил, подтверждаю - механизм в выводом в *.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 |