[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте

Страницы: Пред. 1 2 3 4 5 6 След.
RSS
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Цитата
Daniil Pozdnyakov написал:
К сожалению, нам не удалось воспроизвести
Также как и тут?
https://forum.quik.ru/messages/forum1/message59344/topic6189/#message59344

Daniil Pozdnyakov, просьба более детально описать, что именно пытались воспроизвести, какие действия предприняли и какой результат получили?
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель, Там же русским языком написано:
Цитата
_sk_ написал:
Ниже описывается пример, как большое количество таблиц может появляться в реальной программе. Предположим, что скрипту нужно хранить в памяти для работы 3000 свечей
...
Соответственно, сразу же имеем 3000 * 10 * 5 = 150 000 таблиц. А если скриптов несколько, то можно ещё на порядок увеличить количество таблиц в памяти.
Если какому-то идиоту потребовалось 150 000 таблиц в ситуации, когда не нужно ни одной, то (мягкий) ответ моет быть только таким: "К сожалению, нам не удалось воспроизвести и понять причину описанной вами проблемы". Можно было бы и сразу послать в соответствующем направлении.
 
Daniil Pozdnyakov, плохо, что не нашли причину. Конкретно в последние 2 дня из-за большой активности торгов на рынке у нас терминалы 9.3.3.3, где запущено много скриптов, тормозят: время сервера внизу в статус строке отстаёт от реального времени на несколько секунд. Ненормально это.

Вам же даже код привели, который демонстрирует проблему.
https://forum.quik.ru/messages/forum10/message60158/topic6953/#message60158

Настоятельная просьба провести изучение более внимательно с использованием реалистичных нагрузок.
 
Дополню, что при этом нагрузка на ядро процессора (i7-9700K) максимальная (100% / 8 ядер = 12.5%).
 
_sk_, Причина здесь неоднократно называлась: Квик не обязан обеспечивать работу дурацких тестов единственная цель которых - засрать процессор до предела. Ничем не отличается от других "тестов" и "код привели, который демонстрирует проблему": там тоже создаются никому не нужные таблицы в неимоверных количествах, да ещё и замеряются какие-то несчастные микросекунды. Согласен: изучать проблемы нужно именно "с использованием реалистичных нагрузок", а не подобный маразм. И изучение это приводит к однозначному выводу: производительность Квика вполне удовлетворительная.

Конкретно в последние 2 дня при той же самой активности торгов на рынке у меня терминалы 8.7.1.3 и 8.13.3.1, где запущено ПО ОДНОМУ скрипту, прекрасно работают: несколько десятков сделок в день у каждого и никто не "отстаёт от реального времени", и это нормально! Оставьте в покое техподдержку, доставайте лучше разработчиков ваших скриптов: именно они говно, а не [только] софт Квика.

Дополню, что при этом нагрузка на процессор болтается в районе 30-40% (2 ядра по 2 ГГц).
 
Для снижения нагрузки на терминал пришлось позакрывать все свечные графики (порядка 8 штук), собрать все инструменты в одну ТТТ, выключить там цветовые настройки, а также закрыть стаканы. Кажется, что несколько легче стало. Выходит, что отрисовка графики дополнительно сильно замедляет работу (похоже, что есть там какое бутылочное горлышко в виде одной общей очереди на всё). Трудно обеспечивать тысячи сделок в течение торгового дня.
 
_sk_, Не вижу ничего трудного. Даже у меня при запрете подавать заявки в Квик чаще, чем два раза в секунду (излишки отлёживаются в стеке), "тысячи сделок" могут прибежать уже через 20 минут. Да, ни одного графика, все инструменты и так в одной ТТТ - второй не существует, цветовые настройки раскрашивают таблицу по тикерам, как попугая, и ни одного открытого стакана. И нет проблем! :smile:  
 
Цитата
_sk_ написал:
Дополню, что при этом нагрузка на ядро процессора (i7-9700K) максимальная (100% / 8 ядер = 12.5%).
Правильно я понимаю, что у Вас три терминала КВИК работают и каждый сделал по 12 потоков, а у Вас всего 8 ядер ?
 
Цитата
_sk_ написал:
Вам же даже код привели, который демонстрирует проблему. https://forum.quik.ru/messages/forum10/message60158/topic6953/#message60158
      Упомянутый код демонстрирует проблему в QUIK 9.3.1.11. В QUIK 9.3.3.3 QLua 5.4 эта конкретная проблема устранена. Но, возможно? ,  в QUIK 9.3.3.3 была изменена схема синхронизации в функциях API  QLua (на форуме можно найти много нареканий на ошибки работы некоторых из них, связанных, скорее всего, именно с ошибками синхронизации).
    Существует проблема использования нескольких скриптов в одном рабочем месте QUIK. Это связано с тем, что поток, обслуживающий все колбеки (фондового рынка и таблиц QUIK) один (блокировка в котором блокирует все скрипты рабочего места) и, если в колбеках, есть обращение к функциям API QLua, то все запущенные скрипты рабочего места QUIK, могут выстраиваться в очередь к синхронизуемым ресурсам QUIK (по которым в ранних версиях QUIK, возможно синхронизации вообще не было), что эквивалентно их работе в одном потоке. Если выше написанное имеет место, то решением может быть следующее: между потоком обслуживания колбеков и потоками main в скриптах создаются очереди, в которые записываются только параметры, обрабатываемые в main. Это делается просто, но можно использовать и готовый модуль, код которого приведен по ссылке: https://quikluacsharp.ru/stati-uchastnikov/modul-realizatsii-interfejsa-obrabotki-sobytij-quik-s-ispolzovaniem-ocheredej-sobytij/
 
Цитата
Упомянутый код демонстрирует проблему в QUIK 9.3.1.11. В QUIK 9.3.3.3 QLua 5.4 эта конкретная проблема устранена.
Это хорошо. Полагаю, что разработчики это тоже подтвердили бы, если бы провели разбор проблемы качественно.

Цитата
...  если в колбеках, есть обращение к функциям API QLua, то все запущенные  скрипты рабочего места QUIK, могут выстраиваться в очередь к  синхронизуемым ресурсам QUIK (по которым в ранних версиях QUIK, возможно  синхронизации вообще не было), что эквивалентно их работе в одном  потоке.

Вот как раз похоже на такое поведение. Конкретно у меня в коллбэках минимальные действия и очереди, передающие данные в main, но в самом main остаётся периодический вывод информации в таблицы (имеются в виду окна, создаваемые из скриптов), а их отрисовка опять идёт через поток коллбэков и начинаются тормоза.

Цитата
Правильно я понимаю, что у Вас три терминала КВИК работают и каждый сделал по 12 потоков, а у Вас всего 8 ядер ?

Нет. В процессоре всего имеется 8 ядер. Каждый из 3-х терминалов грузит полностью одно ядро процессора (архитектура терминала такая). Дополнительная нагрузка собственно от Lua минимальна. Основная беда, похоже, с тем, как отрабатывают функции QLua, заставляющие терминал что-то отрисовывать. Что-то там внутри терминала с синхронизациями при доступе к общим ресурсам не так. Пока неясно, как бы это в явном виде продемонстрировать.
 
Цитата
_sk_ написал:
Цитата
Упомянутый код демонстрирует проблему в QUIK 9.3.1.11. В QUIK 9.3.3.3 QLua 5.4 эта конкретная проблема устранена.
Это хорошо. Полагаю, что разработчики это тоже подтвердили бы, если бы провели разбор проблемы качественно.

Цитата
...  если в колбеках, есть обращение к функциям API QLua, то все запущенные  скрипты рабочего места QUIK, могут выстраиваться в очередь к  синхронизуемым ресурсам QUIK (по которым в ранних версиях QUIK, возможно  синхронизации вообще не было), что эквивалентно их работе в одном  потоке.

Вот как раз похоже на такое поведение. Конкретно у меня в коллбэках минимальные действия и очереди, передающие данные в main, но в самом main остаётся периодический вывод информации в таблицы (имеются в виду окна, создаваемые из скриптов), а их отрисовка опять идёт через поток коллбэков и начинаются тормоза.

Цитата
Правильно я понимаю, что у Вас три терминала КВИК работают и каждый сделал по 12 потоков, а у Вас всего 8 ядер ?

Нет. В процессоре всего имеется 8 ядер. Каждый из 3-х терминалов грузит полностью одно ядро процессора (архитектура терминала такая). Дополнительная нагрузка собственно от Lua минимальна. Основная беда, похоже, с тем, как отрабатывают функции QLua, заставляющие терминал что-то отрисовывать. Что-то там внутри терминала с синхронизациями при доступе к общим ресурсам не так. Пока неясно, как бы это в явном виде продемонстрировать.
понятно.
не раз писал , что надо сворачивать окна, которые не смотрите, чтобы ускорить работу КВИК.
-------------------------
Относительно числа ядер для одного КВИК.
У меня квик ( 8 версия) без скриптов использует 8 потоков.
Как я понимаю, разработчики используют рекомендации что число потоков не более чем удвоенное число ядер.
-------------------------
Как Вы определили, что у Вас каждый КВИК занимает одно  ядро?
При одном ядре число потоков не рекомендуется делать быть более 2.  Так как это лишь тормозит работу процессора.
 
К сожалению, движок этого чудо-форума не позволяет редактировать заголовки тем или сообщения.
С учётом полученной раннее информации заголовок темы должен выглядеть так:

Высокая нагрузка CPU в QUIK 9 при вызове колбеков в скриптах, которые содержат много переменных или хранят большое количество элементов в таблицах.

_sk_, посмотрите мои сообщения на первой странице и комментарий Антона #16.
Суть в том, что сам по себе вызов колбеков при большом количестве хранимой информации создаёт огромную нагрузку вне зависимости от кода внутри колбека и параллельно выполняющейся работы в main. Отмечу, что объём хранимых данных (в байтах) не имеет значения. Нагрузка пропорциональна количеству данных.
Обратите внимание также на тест в сообщении #19. Сам по себе скрипт не выполняет какой-либо полезной работы, он только вызывает пустой OnAllTrade(), больше ничего. Увеличение времени работы скрипта при подключении различных библиотек как раз свидетельствует о наличии зависимости нагрузки, создаваемой колбеком, и количеством данных в скрипте.
А тормоза в GUI, которые вы наблюдаете, - скорее всего уже следствие, а не причина.

ЗЫ: версии библиотек qlua.dll, lua53.dll, lua54.dll в QUIK 9.3.3 не изменились по сравнению с QUIK 9.3.1
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
_sk_ написал:
Что-то там внутри терминала с синхронизациями при доступе к общим ресурсам не так.
   Я повторю (так так текст достаточно короткий) то, что мною было написано 10.06.2021 12:57:14.
             Об областях синхронизации.
 Область синхронизации программы это та часть области видимости переменных программы, для которых предполагается обеспечить атомарность (! всей совокупности этих переменных как единого целого) при многопоточной обработки данных.
 Распространенной ошибкой синхронизации в параллельном программировании является непра-вильное определение области синхронизации. Для эффективности синхронизации ее область должна быть минимальнонеобходимой (однозначно определяющей результат программы), обеспечивающей корректность работы программы. Если область синхронизации программы содержит в себе минимальнонеобходимую, то все будет работать корректно (но, возможно, не вполне эффективно). Если же область синхронизации не включает в себя минимальноне-обходимую, то это ошибка программы. Поэтому при разработках, в тех случаях, когда не очевидна минимальнонеобходимая область синхронизации, обычно первоначально область синхронизации выбирается с «запасом». Далее эта область, в процессе развития проекта, может быть «сужена», с целью повышения эффективности синхронизации, до минимальнонеобходимой.
-----
И  10.06.2021 13:59:1.
 Возможно, то, что написано далее, разработчики QUIK хорошо понимают, но на всякий случай некоторые соображения.
   В рабочем месте QUIK объекты синхронизации функций API QLua должны локализоваться в месте, общем для всех скриптов пользователя, и это место точно не global_State и тем более не lua_State. На месте разработчиков QUIK, я бы создал общий для всех скриптов QUIK массив, в котором для каждой функции API QLua выделил элемент хранения объекта синхронизации при работе с этой функцией. Синхронизация должна выполняться не только при обращении к функциям API, но в соответствующих программах, готовящих данные для обсуждаемых функций в потоках отличных от пользовательских.
---------
Цитата
_sk_ написал:
Пока неясно, как бы это в явном виде продемонстрировать.
   На самом деле, достаточно показать, разницу по времени выполнения в разных версиях QUIK и, как я понимаю, пользователями в этой ветке сделано.  Для разработчиков QUIK этого должно быть достаточно.
 
TGB, На месте разработчиков QUIK я бы просто запретил использование более одного скрипта на терминал. Или, по крайней мере, считал бы их полностью автономными задачами, не требующими вообще никакой синхронизации. Тачка просто летала бы! Что, собссно, она у меня сейчас и делает. :smile:  
 
Цитата
_sk_ написал:
Для снижения нагрузки на терминал пришлось позакрывать все свечные графики (порядка 8 штук), собрать все инструменты в одну ТТТ, выключить там цветовые настройки, а также закрыть стаканы. Кажется, что несколько легче стало. Выходит, что отрисовка графики дополнительно сильно замедляет работу (похоже, что есть там какое бутылочное горлышко в виде одной общей очереди на всё). Трудно обеспечивать тысячи сделок в течение торгового дня.операций
Так и есть вся визуалка, особенно обновление графиков, жрут все время процессора так ка все это выполняется в одном потоке. Поэтому обнавление таблиц позиций например, появление окон настроек и т п дополнительные вызовы приходят с задержками. А нагрузка процессора всего 15-30% . Хоть 100 ядер себе поставьте квик все равно будет тормозить. Тут важна скорость обработки данных именно в одном потоке.
В вин рар есть тест быстродействия альт+8, вот там и показывает скорость обработки. Для квика только в однопоточном режиме. У меня Общая скорость 1200 кб/сек. на fx 4300 проц.
                       
 
Цитата
Старатель написал:
К сожалению, движок этого чудо-форума не позволяет редактировать заголовки тем или сообщения.
С учётом  полученной раннее информации  заголовок темы должен выглядеть так:

Высокая нагрузка CPU в QUIK 9 при вызове колбеков в скриптах, которые содержат много переменных или хранят большое количество элементов в таблицах.

_sk_, посмотрите мои сообщения на первой странице и комментарий Антона  #16 .
Суть в том, что сам по себе вызов колбеков при большом количестве хранимой информации создаёт огромную нагрузку вне зависимости от кода внутри колбека и параллельно выполняющейся работы в main. Отмечу, что объём хранимых данных (в байтах) не имеет значения. Нагрузка пропорциональна  количеству  данных.
Обратите внимание также на тест в  сообщении #19 . Сам по себе скрипт не выполняет какой-либо полезной работы, он только вызывает пустой OnAllTrade(), больше ничего. Увеличение времени работы скрипта при подключении различных библиотек как раз свидетельствует о наличии зависимости нагрузки, создаваемой колбеком, и количеством данных в скрипте.
А тормоза в GUI, которые вы наблюдаете, - скорее всего уже следствие, а не причина.

ЗЫ: версии библиотек qlua.dll, lua53.dll, lua54.dll в QUIK 9.3.3 не изменились по сравнению с QUIK 9.3.1
Колбеки выполняются в основном потоке терминала КВИК,
Поэтому, когда у Вас исполняется колбек терминал КВИК курит бамбук.
Если Вашему main надо данные получаемые основным потоком, то ваш main тоже курит бамбук.
и не важно сколько у вас ядер, все ждут основной поток, а тот ждет когда ваш колбек закончит ....  
 
Цитата
Старатель написал:
Высокая нагрузка CPU в QUIK 9 при вызове колбеков в скриптах, которые содержат много переменных или хранят большое количество элементов в таблицах. _sk_ , посмотрите мои сообщения на первой странице и комментарий Антона  #16 .Суть в том, что сам по себе вызов колбеков при большом количестве хранимой информации создаёт огромную нагрузку вне зависимости от кода внутри колбека и параллельно выполняющейся работы в main. Отмечу, что объём хранимых данных (в байтах) не имеет значения. Нагрузка пропорциональна количеству данных.
 Anton  :
 «Сложился паззл. Когда в девятой версии смотрел "чего нового" в отладчике, увидел, что после каждого колбека lua_gc добавили. Не обратил внимания только, полный или шаг.»
-----
   То, что написано коллегами выше достаточно для того, чтобы устранить обсуждаемую ситуацию. Скорее всего, надо убрать запуски мусорщика (lua_gc) в колбеках. И вообще, не надо разработчику трогать уборку мусора.
  Что из выше написанного непонятно разработчику QUIK? Какие есть возражения по предложенному варианту устранения ситуации?
-----
   Если же, вдруг, непонятно, написанное коллегами, то  я попытаюсь детализировать их сообщения.
  Запуск  уборки мусора в колбеках это такое «ноу-хау», от которого «оторопь берет» :smile: . lua_gc одна из самых сложных и тяжелых функций Lua. Особый цинизм состоит в том, что сборка мусора запускается в колбеках. Пусть поддержка/разработчики QUIK объяснят, зачем это делается?? Что при этом решается?
  Разработчик QUIK понимает, хотя бы приблизительно, как работает сборка мусора в Lua?
Приблизительно работу мусорщика можно описать тремя пунктами.
1. При запуске функции lua_gc, работает только эта функция.
2. Время работы lua_gc зависит от параметров ее запуска и, как минимум, пропорционально количеству переменных, используемых в скрипте:
  1) собираются все используемые в текущий моменты области памяти скрипта (и для этого во многих случаях надо сканировать все объекты/переменные скрипта);
  2) те области памяти, которые не попали в список, собранный в пункте 1), возвращаются системе.
3. Если не «химичить» с принудительными запусками мусорщика, он будет запускаться автоматически в какие то моменты, определяемые состоянием памяти скрипта и его настройками. И это будет происходить, конечно же, не с высокой частотой возникновения колбеков.
 Если же моя попытка объяснения деталей проблемы не достигла цели, то вот цитата из книги «Программирование на языке Lua» Р. Иерузалимски:
   «В другом крайнем случае сборщик может производить полный цикл сборки мусора при каждом изменении графа доступности. Такая программа будет использовать самый
минимум необходимой ей памяти ценой гигантского потребления процессорного време-ни»
----
  Зачем разработчику QUIK «гемморой» с принудительным, бессмысленным частым запуском уборки мусора, да еще в единственном общем потоке обработки колбеков QUIK?
  Пусть с этим разбираются скриптеры (если знают как).
 
Цитата
TGB написал:
надо убрать запуски мусорщика (lua_gc) в колбеках
Я позже разбирался с этим, запуска сборки как таковой там нет, это вызовы отключения/включения сборщика. Но при включении сборщика есть побочный эффект - сбрасывается переменная debt в стейте и, получается, на следующем шаге сборщику придется оценивать количество мусора заново (как минимум, а как максимум он еще и шаг сделает). Это совершенно недокументированная особенность луа, так что я б не стал арку в этом обвинять. И там есть некая переменная, уже аркина, которая неизвестно что содержит, я не проверял под отладкой. Возможно, даже этих отключений сборки не происходит, хотя, судя по наблюдаемому поведению, они таки есть.
 
Сборка мусора - это идеологически ущербная технология, аппендикс на теле программирования. Первый же вопрос: "ОТКУДА этому придурку знать, какие объекты стали ненужными?" вдребезги разбивает всю конструкцию. Уверен, что глубоко почитаемый мною Джон Маккарти и в страшном сне не мог предположить, какой ящик Пандоры он открыл в 1959 году и насколько она станет востребованной несколько десятилетий спустя: надо же засрать поцессор лишней работой! Надо же поднасрать программисту с памятью, которую он наивно считает "своей"! В результате одно криворукое стадо, не умеющее обращаться с памятью, пользуется услугами другого криворукого стада, которое эти проблемы "решает". Если программер расписывается в собственной несостоятельности при работе с памятью и полагается на эти долбаные "сборщики мусора", если он не знает, что делать при ошибках в своём же коде и полагается на эти долбаные "try…catch", если он неспособен даже определиться с типами его же собственных данных и полагается на эту долбаную "динамическую типизацию", если он добровольно соглашается на все кастрирование своих возможностей, неизбежно появляющиеся при таком подходе (работа с указателями, преобразования типов данных и т.д.), то из-под его пера может выйти ТОЛЬКО говно, столь же изобилующее ошибками, но куда более хитрыми и труднонаходимыми, с которыми уже не только он, но и никто другой не справится уже НИКОГДА! И возникающие при этом тормоза здесь чуть ли не самая малая плата за такой подход к программированию. Точнее, самая заметная - остальные глюки тоже никуда не денутся.
 
Цитата
Anton написал:
не проверял под отладкой
А теперь проверил. Коллектор выключается на каждом OnParam и каждом OnAllTrade. Вариант "оно отключено и не влияет" отпал.
 
Цитата
Владимир написал:
долбаные "try…catch",
Цитата
Владимир написал:
тормоза
Наоборот. Без try-catch у вас будет
Код
if(call(... if(call(... if(call... if(call(...
и так далее на всю глубину стека вызовов. Идея в том, что эти все иф никогда не должны исполниться. Вообще. Поэтому их и не должно быть вообще, а должен быть блок try-catch, который работает безо всякого оверхеда на основном пути. То есть там нет ни одной ассемблерной инструкции, не говоря уже про аццкий иф, ломающий конвейер.
 
Anton, У МЕНЯ?! Да я ещё 20 лет назад писал в своей "персональной" ветке:

Блин! Теперь у меня ни малейших сомнений: exceptions надо давить в зародыше!
(...)
Мужики! Мне просто страшно читать о проблемах, какие при этом возникают! Да на кой нужно такое счастье? Стек - это просто LIFO. Заказал ты под него динамическую память или она из тела программы - вторично. Хип - та же память, только в профиль. Надо 5-10 стеков - пожалуйста! Надо отмотать - пожалуйста. Надо диагностику по аварийному выходу из хрен знает откуда - пожалуйста:
for (;(INT8)(*_OS).iPush >= 0; ) // если стек параметров установлен
_PopAllData (); // восстанавливаем спрятанные за Push данные
Работает, как часы. Просто до неприличия - с вашей квалификацией практически любой за пару часов напишет. Ну, "восстановит" она какие-то объекты в стеке, из которого мы уже умотали - был один мусор, будет другой. Но наши-то ТОЖЕ ВОССТАНОВИТ!
Ужас! Завязывайте вы с этими исключениями!
https://forum.ixbt.com/topic.cgi?id=40:160:61#61
 
Просьба к разработчикам терминала написать адекватные ответы на вопросы, поднятые по существу этой темы.
 
08.02.22 Выложена версия QUIK 9.3.3. Похоже, взамен того, что было выложено в конце 2021 г.
----
Среди исправленных недоработок:
Медленная работа Рабочего места QUIK в некоторых случаях при запуске или во время работы.
Но это надо, наверное, проверять.
 
TGB,
#78. #162
Цитата
Старатель написал:
версии библиотек qlua.dll, lua53.dll, lua54.dll в QUIK 9.3.3 не изменились по сравнению с QUIK 9.3.1
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Daniil Pozdnyakov написал:
К сожалению, нам не удалось воспроизвести и понять причину описанной вами проблемы.

Daniil Pozdnyakov, просьба более детально описать, что именно пытались воспроизвести, какие действия предприняли и какой результат получили?
Надо делать так, как надо. А как не надо - делать не надо.
 
Здравствуйте.
     
Прежде всего приносим извинения за задержку с ответом.

Если посмотреть на первое сообщение данного трэда, то заметим, что "...никто не запускает скрипты с тысячами функций, но при нескольких     запущенных скриптах с десятками функций при высокой активности на бирже получаем нихилую загрузку CPU.", возникают вопросы: "сколько конкретно скриптов ?", "Какие конкретно функции используются в данных скриптах ?", "Какие конкретно параметры ОС".

Так как данная информация представлена не была, тестировали скрипт обособленно. Получили следующие результаты:  
До запуска скрипта:
(см. скриншот До_запуска(1) )

Запуск скриптов с дополнительными окнами, стаканами и ТОС :
(См. скриншот Запуск_скриптов_с_дополнительными...(1))

После запуска скриптов:
(См. скриншот После_запуска_скриптов(1))

После того, как данное тестирование результатов не дало, начали анализировать сообщение #19.

Результаты тестирования следующие:  До запуска скриптов:
(См. скриншот Сообщение_#19_До_запуска(2))

запуск скриптов:
(См. скриншот Сообщение_#19_Запуск_скриптов(2))

После запуска 3 копий скрипта, а также перезаказа данных (Важно  отметить, что на мгновение загрузка CPU действительно выросла, однако  это вызвано перезаказом данных):
  (См. скриншот Сообщение_#19_После_запуска_скриптов(2))
 
Добавим, что данные обращения тестировались, как на версии 9.3.1.11, так и на 9.3.3.3.
 
После этого анализировали  обращение под номером #51.
 
Вот, какие результаты были получены, не подключаясь к серверу.
(см. 2 скриншота #51_результаты...)
 
На основе этого и было написано, что проблему воспроизвести не удалось. Важно  добавить, что данную проблему перепроверили вновь ещё раз по обращениям в  данном трэде (отражено на скриншотах). Если есть какие-либо  дополнительные параметры запуска, просьба их уточнить, также просьба предоставить конкретные параметры ОС.
 
Ещё, если в процессе воспроизведения проблем, описанных в данном трэде, с  нашей стороны были допущены какие-либо ошибки воспроизведения, просьба это уточнить,  перепроверим.

Приносим извинения за доставленные неудобства.
 
Сообщение #51 не моё, оставлю без комментариев.

Daniil Pozdnyakov, я правильно понимаю, что тесты проводились на Junior, где количество всех инструментов (если не считать информационный класс) чуть более тысячи? Из которых более половины редко обновляются или не торгуются вообще.
Для справки: у меня в боевом квике, в котором открыты только стаканы и графики по 8-ми фьючерсам, "умный" заказ сформировал список из более 30 тыс. инструментов, которыми я вообще не торгую и не открывал даже. Плюс ко всему инструменты на бою обновляются на порядок чаще, чем у вас на демке.
И все изменения параметров по всем этим инструментам вызывают OnParam во всех скриптах, где есть этот колбек.
В таком случае и количество скриптов и/или количество данных надо увеличивать пропорционально. Это, конечно, если цель - разобраться в причинах повышенной загрузки, а не просто отчитаться "запустили/посмотрели".

Цитата
Daniil Pozdnyakov написал:
"Какие конкретно функции используются в данных скриптах ?"
Исходя из вопросов, ясно, что никто ни черта не делал и даже не читал тему. Вижу, что "тестирование" (если это можно так назвать) проведено на от#сь, совершенно без включения мозгов.
Как я отмечал, оказывают влияние не только функции, но также данные в локальных/глобальных таблицах.

Позже дам комментарий по сообщению #19.
Думал, для людей с технической специализацией оно будет понятно. Видимо, придётся расписывать для тех, кто с компьютером на "Вы" и то шёпотом.
Но на это потребуется время.
Надо делать так, как надо. А как не надо - делать не надо.
 
Комментарий к сообщению #19

Тест на Junior 9.3.3.3.
Скрипт:
Скрытый текст

Поочерёдно раскомментирую одну из 4-х первых строк и запускаю скрипт. Далее делаю перезаказ обезличенных сделок:
Система / Настройки / Основные настройки... -> «Программа» / «Получение данных» / «Обезличенные сделки».
Выбираю класс "Акции 1-го уровня (эмулятор)" -> "Перезаказать данные"

Результаты:
Цитата
0: 11.491
100: 27.39
socket: 22.735
iuplua: 31.276
Оговорюсь, что сейчас помимо тестового у меня запущено ещё 3 квика и несколько других приложений. Поэтому результаты могут быть искажены.
Но позволяют сделать следующие выводы:
Цитата
Старатель написал:
Сам по себе скрипт не выполняет какой-либо полезной работы, он только вызывает пустой OnAllTrade(), больше ничего. Увеличение времени работы скрипта при подключении различных библиотек как раз свидетельствует о наличии зависимости нагрузки, создаваемой колбеком, и количеством данных в скрипте.
Надо делать так, как надо. А как не надо - делать не надо.
 
Как же достали эти вечно скулящие умники!

Ну, я когда-то тестировал более 20000 инструментов, большинство из которых прекрасно обновлялись и торговались. А тут проблемы с неполным десятком? Это как же нужно уметь программировать!

По поводу "умного" заказа - вот фрагмент моей переписки с брокером:

Добрый день. У меня в последнее время появились нарастающие проблемы с Квиком:
1. Загрузка самого Квика происходит неприлично долго, причём это время постепенно увеличивается.
2. Сегодня Квик отвис...

Проверьте пожалуйста наличие фильтров на получаемую информацию, возможно они сбились и сейчас программа запрашивает информацию в разы больше чем вам нужно. Для проверки фильтров нажмите F9, потом котировки, должно быть так: (...). Потом в обезличенных сделках справа должно быть выбрано желательно 0 , т.е. ( 0/…):

Да, в настройках стоит именно "умным заказом". А вот обезличенные сделки я вообще не использую - может быть, их можно как-то отключить? Ага, у меня там куча галок стоит - всякие там кросс-курсы, опционы, акции, облигации, а у Вас ни одной. Если я правильно понимаю, то "умный заказ" и так обеспечит получение необходимых данных?

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

Даже сейчас читаю просто с наслаждением! А здесь... ЗА КАКИМ ХРЕНОМ Вам "и количество скриптов и/или количество данных надо увеличивать пропорционально"? Сделайте ОДИН скрипт и пихайте туда только НУЖНЫЕ данные! Тогда любой процессор потянет не Ваши несчастные "8 фьючерсов", а все 800! И покурить при этом успеет, и кофейку попить. Это особый талант нужно иметь, чтобы выкапывать "повышенную загрузку" в задачах, которым любой старый велосипед годится!

И Вам задали совершенно конкретные вопросы: "сколько конкретно скриптов?", "Какие конкретно функции используются в данных скриптах ?", "Какие конкретно параметры ОС". В ответ снова гнутые пальцы, ибо по теме сказать тупо НЕЧЕГО! Чел со сраным десятком тикеров справиться не способен, но он "с компьютером на "ты", панимаш! Тьфу!
 
Демонстрация CPU Usage в Junior 9.3.3.3

Скрипт:
Скрытый текст

Заказ обезличенных сделок:
Скрытый текст
Получение данных: снята галка "Запрашивать данные раз в ... сек."

1. Загрузка при запущенном скрипте с n = 0 и открытой ТТТ. В ТТТ добавлены 4 класса: те же, что и в ТОС, со всеми параметрами.
Скрытый текст
Практически нулевая - скрипт не оказывает никакого влияния.

2. Загрузка при запущенном скрипте с n = 5000000 и открытой ТТТ.
Скрытый текст
Загрузка стала больше. А что изменилось? Только добавился массив, больше ничего.

3. Загрузка при запущенном скрипте с n = 5000000 и закрытой ТТТ.
Скрытый текст

Daniil Pozdnyakov, если у вас не получается проделать то же самое, готов продемонстрировать на компьютере вашего тестировщика по RDP.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Демонстрация CPU Usage в Junior 9.3.3.3


3. Загрузка при запущенном скрипте с n = 5000000 и закрытой ТТТ.
    Скрытый текст          
Daniil Pozdnyakov, если у вас не получается проделать то же самое, готов продемонстрировать на компьютере вашего тестировщика по RDP.
Для полноты картины не хватает теста с открытой, но свернутой ТТТ.
 
и еще тест со свернутыми всеми окнами не квиковскими окнами.  
 
прикольно, что куча тестов кучу раз вызывает колбеки,
которые кучу раз дублируют одну и туже информацию.
-----------------------------
В качестве пожелания:
Может имеет смысл сделать вызов колбеков один раз для всех скриптов и  все их спрятать ,
чтобы не пугать буратин
и не давать им возможность грузить CPU кучей бессмысленных скриптов.
 
Для слепых, тупых и троллей: здесь один скрипт используется.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Для слепых, тупых и троллей:  здесь  один скрипт используется.
для особо тупых
----------------
запустил Ваш тест на боевом квике
------------------
вот результаты:
это без теста
[img]data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAjQAAAAYCAYAAADtemdnAAAJtElEQVR4nO2dz28b1xHHv3LdxHWNJDVouEV9KCqvVhX1HxDwwSeJdbSXUml6qwkBclFKgKLw0AKhWCAtsFFVkIICBSpt10aQmBsfVlYpnXxwQcBoDkkArqAVrSpBdVFMGI5Tq7Ujij3scvlI7tsfFB3rx3wAAdzd92bnzfvB2Zm3YsdaqVIBQRAEQRB7gvLWBo4ff+F5q7Gn2dp62mSjI89JF4IgCIIgiLZBDg1BEARBEPsecmgIgiAIgtj3kENDEARBEMS+56ifwr/7u4x79z8HAJw99RP88efxZ6IUQRAEQRCEHzq8vOX0G+X3uP/4ge21U98/iXcjb7ddMYIgCII4jNBbTu609JZT5OolrjMDAPcfP0Dk6qXda0cQBEEQBNEijg7Nr/7229pBeQfH1h/hxMdf4sTHX+LY+iOgvGNflouCWKADndZfL9K6D231JPoCHegMJVH0UY1wQ0HMb18QBwM9ib7qfGI/H3CKci+zDnWgM6owV+3mA3tOQSwwiJxtWQ3pUKM8gjio6JgKncaZgPE3rHKKqUNWmfNybWKtyuds6y5EHWQ5wHVort1V8E2lbByUd3Dy04e4nnwfV2Zu4srMTVxPvo+Tnz60nJpvKmVcu+tlEgcxmq9grVTBUhxIXfSwgFYdmYvAdKmCtXwCgrf2EQThhJjAtKSYDwoTEOIHf24V5V70yT3GWmL+TWOwLU5ILtqLnFTAWibSBk0JYq+joyu+iY3SJjbyb2I1OoSFpiKTOB8FZkub2CjNoUsewpQOAPOYUgdw2zwPeRKrZvkpzGFW8q8N16H5h37X+nziiy28N32jqcx70zdw4ost2zpeEOIJhHUFi46RAQ3pixMQMuTIEMSzQIgXal/sLSwi+wo9iZjcg+lSFmHmdDhTwOhKcldRyqLcixiyWIoHd60mQewPBnChumaIXeiyKbGqzgPxcVwwy4/FgQWVN9F0TF3UMZYZaEkbrkPzsPzY+nzlD9e5Athrj8pb3HJeyEXtQsDLKOoRCHotRNwna7VK1eiN+RezwlSNoeCG47p61fCxw3mwcprTXkYI24P8akja0rf+uK48t22N+tTuW6+Hiw2sFOAgctCQCtmkAd3sq9au1/rFm43s+9tJZ6e2etDVg0znccLrA6CxX731owcbVv/YtBBXlk15H3ZpsqdD+wwZbvVbHetsOsdtHPHSpZzzKxqKUqTOmTEI4my3hpyqNV3xhDqIPjWCJYrMEIcV9RYWpFdNx8ULAxiT5nE+cBpnAkNAfByQh7Aan/Mhox7+HpqdHe4lfpWyr/JFOYmcGEG/aByHM9UQcBZh1Xxa0pdRhIIcbljXBLm3tqCGzOhNqYK1/ASKUS97QRTEQgrCZuprLQOkZc3hfCNBCGAjSxoWdTDRI54cDemQGZK2noiDGMmbbbbScVmEW2qbgrQKj1EsDenQIIrxQv29Mz1IhZgvFEcdNKTkahpwApBfY6652YjT355pbGurY8H5Ht5lttqPzjaspmeN6KSbLOa+umY6AV7b4DR27MatW32/Y50379zHkR+K+jL3miC2GlnRkJIVhA9Buo4gGrH2wcy/ig2byEqXKGJVnjRTUXpddKYrfsdIV5U2MSsZKaixXUSJuQ7N0f/V3ua+eucDrgD2GluHTzUS0GHksdk0kjrIiYxEMGKFcY3PRV0znZ0I+q2QVwIjkobiSu1etc8M+jKKjB6dUcVY6HjnbQhLPUjJZlRBNRwzwVX+R8jpbFsccG1bM7noINC0qDJ61EWiOLpICYyKChZVLzoEMXrZvJ+Nfo42Ahz6252mtnoYC7Z2cLSRg0zXSJ5XvZxt6E9WtR2DQMZMqXgcR/Zjp3pf93Hb3B9+xzp/3rmOo7r+c4qiAYLY466Pb4IYzbTDgSaI/YfllAzcwpnAOXN/DIM0h9txHcNmJGa1W7SVsxCdRNflcYCzUdgLXIfm5JPa+91L/8pzBbDXfvDEy3vzzFMnm8fWk+iLmk+qpQJGq20We1p86jEW01pao9lJYjcF1jbx8c43ICUwuqIgByA3v4yw1LhQepTTLlaSSCNr8+TMsXfb0XCv8YvYyUa8/vYCt61OONmhBRuJCSyV2m1XGxv6otqOAgTZx5drS/ZsY30AjvPFda4x/ZeJICc7vGjQHYSgKjYOqIZFFQhLQQA9EBrHo76MInpwljdOuxNYqotuEsQhQ5rDrKRj1WYNq0Vi7uACdHSJDRNJn8QUxjEmNm8U9gPXoZl5YwbYNtJOZZTx+rUYPvzklnX9w09u4fVrMZRhpJmO/Hcb774x4+vmdaxoKIpBw3nRP0LOWowj6JcUJgRtfBbEoOnsmNEEANCTSKu1p1F2s2Pdl45ZrymdxDtvSxD90jLSchKLSGCE7R+u/F8gLHqU79K2ejSkogrCcR9OE08XNYmUbt7HVQdmz4H5RF6vn4ONuP3tBqetvuzlkXbI3LUNW9XHjMJ4uL/r2HEct7z+8D/W+WUdxpFfxARGJAWxun05Rnos1V2VbeynYd/AzMkTnL03DFIWS/HlBtkEcYBR55m3muaxoIro6jY+D9tFa9QhDK+82ZBW2t1GYBbHnz54ufgffPWzlwAA2zvbuPlZDjc/s3n+2Kngh//2v+emDimBUbkXfYEJQIwgzCxa4UwWi4FedMrGsRAvYEkCgAim8xPoC3WgMwoYT2oFD0/L1Xo1mZCyWMvwz9shxBMQAoNApgKAfeWTL2ckn0WRaUs4w3uzxF/bhPgNnwt9sEkXhDqQqruPmw5BCPpr6AxoVlsa9ePayKG/qymEFHsqNIizpYhDW1sdC060Q+bubehdFmM3KYs1j3PEfew0jxV23NrXd65j367G+cLqyJtrDe1GEKP5LISmMjXCmQqE6thj9B29HGHKFHAvxJQRJ7CUd39gEOIFTOsd6AsBa/mEa3mC2Nd0r2IqcBrD5uGFzCbGmtaCeQwHqq9zD2C2NF73NtSqPIQFaQ63zetj0jmcD7xjyfOD608f/Hokgq3ul7Fz/LvcMkcfPMEHY5d93ZjYSyiIBZIQ8gUfTlErdVpFQSygoP+ZpsyeB9+mDQlH9CT6QhMomg4f9QfxPKGfPnCnpZ8+uJJW8NN14Nj6I3znq6fGyfIOjnz91Crzyvdeaq+mBEEQ3ybWnihyZghiv+Lp17b/9M5fAQBvvzWGz/9ZxIsvvoBTp3+E9e37eCy+gspRV7+IIHZBBNMl+v8eBEEQBB9Pv7btxKXYL3Gs58f4y6U/t0sngiAIgji0UMrJHbuU064dGoIgCIIg2gc5NO60tIeGIAiCIAhir0MODUEQBEEQ+57/A/o2osNU512BAAAAAElFTkSuQmCC[/img]
это  исходный тест  n =5000000
[img]data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAkYAAAAhCAYAAAA8s2SnAAAKMElEQVR4nO3dT4jc1h0H8K82trehdpzE25Rxe8ihwVjSxaQHF8Peeiv44HmycQ8pCRQCDbitMYUaJJXtZanbxVBSimPsNHF39cYH1yVt0xKwYcteWpdGT2bJoTUsHeI/if/V9a53Rz2MZkYzo38zK3vt9fcDCzvS09N7T0+an96TdrVTp06FICIiIiJoYRgyMCIiIlpnrgWnsfXLX1jrYjzWbn16H1/aWu9aNrJGZSEiIiJ67DAwIiIiIoowMCIiIiKKMDAiIiIiijAwIiIiIopsWIudfufMJPz6vwEAZuVlnDp4ZC2KQURERNTlkb6u/61f/xj1O58lrqtseRG//+5PH1VRiIiI1jW+rp+v8Ov6DyNWevXYm6lBEQDU73yGV4+9Wfp+iYiIiIrqC4w+/vhjXLhwAY1Go7SdfOMX3+t8WGlg85Xb2HbpKrZduorNV24DK43ktKkkLE2D1v4x4aoBCqRcmJoGzXQxyGaUR8Ia9FjQ+qBcmK3zKf77OqdcM3Yd0qBZMrY26XyIL5OwNAsyMa2Ca/bmR7T+BZOHMbqnhiAtwbkpjI5N4WzvNmMHMDp2AAfPdZaffaP7c1FdgVEYhrhx4wbq9TouXrxYSnA09ZHEUmOl+WGlge3+TVw4/j4+fO8sPnzvLC4cfx/b/Zvt4GipsYKpj4pcDAw4fogwDOE7gLO/wIW4FRDtB2bCEKFvw1hN5YioybAxI2R0w+FAt9f/uaVcE6ajwwub16EwDOHBKiWYkZYJKXyEniihpERPijlMTC6krFvAxJ4DGP0dsK93m3O7cen6NBavHwImo6BqvoYJHMKZvYOXoisw0jQN4+PjqFQqpQVHf/jnXPv3Fxbu4fy7M31pzr87gxcW7iVuU4Rh2xBKopYZGSm4+x3oHgMioofBsP1OgLDev8+Vi/2ODi/0EK+q8Hw4gbuqUVPlmrDgwbd5laKnSzBZA45UoSeu/SqOzk5j8Z3dBXJawMTrCzhaKG2/vqm0kZGRUoOj6w/+2/79L8d/k5ouvu7zB/dS0xUhraSh7QBKCRhBZ+jbjF+9WqNJ0U/npq93iLvnc9d2rWHxjOWI59M/ndccmi+Qf2uovV3e7s9d6VPr1luezn67y5HTBu2pTQsSCo6ZML2Z176ys75zXIq1UfLxzipzVl0LlLVAntn9JO0YAL3HtdhxLNCGrZ/4dFdqXgnpB2iXvvbMqF8zj7zth+3r8WmqvH6UNg2csjxQUEKgP/4zoOsKMvsuLV3NgikF/HUfWRL1mK/h2/PVIUZ4duPo3jnsGjuA0bEp4EgVmJxCcORQz8hScYkPX4+MjGDPnj3YtGkT6vU6Ll++PGT2gDZEUNVoTb0VpFwX0hCoRjdYwmsNbXsQMrp7UwECSEjMtNfpjtm5MJvRaFIYIvQdBFaRZ2UkLFNCRFN6oQe4rspY3suAgfhIl0JNITaalZaPgmtGQ+3tO3QDth/VuT3N6EEMVTcJV6LgqJqCa1oIHL97354Ox4x9MWWWQcFxW9ObDuDsj63La6OU411Yb12H7QvZ+yie57DHMbsNW9POzdHSvLxi+1UqmusvWoesvpPUb/O2H7Svp513+f1oECpIfQICujF0rnAcCfEUTEMSdVvAxOtz2HdkuBEe/cjPsHh9GovXp3Fmb3Nq7egQU2gtiYFRo9HA7OwslpaWUKlUsHPnzqF3sHGx84bbz//429R08XXxbdK1Ria05jx/fHpMWikjNQJ2e3hawHYMBIGKgiYB0bpIGzZsoaDa17747/EiBAhi5dAsCaWC9OUJhNDhuFEpZTPA03Pzr0GqeF2ymimvbv2kZQG23TOcGStH18hYSlmEDceQkLJIGQw4M9HxSyhfZhs1C5wxMpetr64F+kJiO2S2UUaeuSOLRcuV3YaD5dWqhwV40VRRwX6U3Hda2eb32/7jMWhfTz/vcvtR1/HLGtUDDD15sH91DDheGYE40ZMlmJzC2b2HcHTH6vM6+0YN+skqkPJAdhF9gVGj0cDFixdRr9dRqVQwPj6OkZHh/0D2S8ub2r/PBLOp6eLr4tuki90Fx+f5lQvTQvRApA+ndT019JR5yzzNAKozXdMfbMUfvuw8LJm2vEfVhhNISABSBhDV3lIWzKcsgQsXXsKdfEp7l06h72Y8q43SjncRqXXNktUOQ7SRYcMPy27XhDYcSKsePgx3gC/podqzxO0BZJ4vueda7Ph5AtLNeKFDN2BImRDIKtQkIKoGAB19g0cqQAAdelo/1W34XaOtROtd84Hr9ptle2oI5mvYlfVmWpr5GiZQxdEd/Q9kD6LvrbQygyIAOPeTXwLLzem05XAFu6fewtuz59vr3549j91Tb2E5bE6fPXN/ubnNsAIFZRjNIEjVINtXNgEhZGxoXcJ1FHTdiIKmaHQDAJQLV3bujuMPlXZ9eUXb9U2TpS1PZKAqAriuCwkbXTfGqflXIYyC+efUrZuCY0kIe4BvprSySBeOivaTW4bYMxnRCEF3+TLaKPV450mp60DtVVAZea66DYctTzQqVGD/uX0ns9+mHY/B+3p62ox+NCjDhi0krK7nlprTfo7eyrv5vFH8jVnpOinPJsUID74T9ORNtF7txploGmzx+jQWZ6vQd1RxabYKHXM4OHYYE/NF8lndA9dxXf8SRNM0bNu2DQBKCYpaXvrXXVx95TkAwIOVZZyY+wAn5j7oT9gI8XJ9lX8iQNhwXBOm5gCGgIhd/ITnQWomNKf52XB8+AIABDzfgWlq0Jpr4Ph+gbv31nadPCE8hF768iSGbUPXLMALga77xPR8bN+DitVFeGlvAg1WN8OZGfALw+grizQ1OF37ySuDAV3th6apdl16y5faRhnHuzU14sSWSNOCHoqMug7bF7KUkefq27B4XrF2Ex7CgudIft/p7yvxfpu8ffY2yfXqPV9iuaWeaz31hgHH92BkjNsIL4Tf6nux8jozIpbGh2PG0hgOfD//yBu2D09pME0g9O3c9ERPu9Z03CUAzQeyD2PXWHOkaN870wPllfgvQcIwhKZpJRS145uvCdx6ZStWnt2Ymmb080X8deJkqfulR0nC0lwYvj9AcDXMNsOSsDQJ8VCnAtfCo2xDyqRcmKYDFQWOPB60lvgvQfIV/pcgZQdFAPDn0xLmArD5ym1svL3UXLjSwDN3l9ppXvzic6Xvl4jokWk/M8agiOhJtSE/SXlO/uoEAOD7P/wBPvn7Jxgd3YRKpYLLC9dw82vPI9xQztQdUTIBL1xfY0VERFSuxKm0tbD3tQMY3fkVeD86ttZFISIieuJxKi1f0lTaIx0xynLu9GAPRxERERGVjXNXRERERBEGRkREREQRBkZEREREEQZGRERERBEGRkREREQR7U+Xlx+L1/WJiIioPF/f8g/8Z3nLWhfjsbZ9wx18er97mXZ38fH4O0ZERERUnsVrf8Ozz29d62I81v538xY2b+6ePONUGhEREVGEgRERERFR5P+8fsobYtgWHgAAAABJRU5ErkJggg==[/img]

это n=0
[img]data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAkYAAAAcCAYAAACEV3DUAAAKeklEQVR4nO2dX2xT1xnAf84oZR3qH+o2Q+NhWnCcxnmbWqmyxkOfgkfxy5yuexsREkxzIqXUD5s0x5O6SReWKYmoqJiBUVUtcXlwYCZPlcrktSqa2mpxxo2b0WpIVcDtKBvZCtjew722r+37z8YQCN9PsnTvPf++851zj7/7fefanmPHjpURBEEQBEEQWHdx4w9WWwZBEARBEG4DQ8+s573FL1ZbjLuaZ3sfr9ORZ6lQFo+RIAiCIKxBiisXeeih9astxl3Nysr1Oh11raIsgiAIgiAIdxViGAmCIAiCIOiIYSQIgiAIgqAjhpEgCIIgCILOutVq+Bd/Uvjk8qcAbH3iu/zmh7HVEkUQBEEQBAFYhbfSfpb6JZevfWma9sS3NvFq5JU7KY4gCIIgrFnkrTRnXL+VVr4N9lLk2F5Lowjg8rUviRzb2/F2BUEQBEEQ3GBqGKkLf+ODv7xLqVTqWEM/+ePPayfFEhsuXGXjuUtsPHeJDReuQrFknteSFFGvh57qZ4AptQWB1ASDXg89wQT5FooJTqSItjoWwtpATTBYuZ+Mx2ucvDJgWIc89AynDKlm94PxWoqod4iMad4cU8HG+gRhraIyEexmi1f77Enb515UtrEleIBF47lJ2dPDznU10mQYlctlrvzrCy4tf8659852xDg6/n6KG+WidlIssemjK7yeeIOjB09y9OBJXk+8waaPrlSNoxvlIsffd7MYBBjNllkqlJmLweQuFwtxxSDaBdOFMkvZOL5b6ZwgCBr+ONPhlP7AMY4vtvbvrbwywKDSr60l+meaoY4YM5nhATLheZaSkQ5IKgh3Oyq9sWUuFpa5mH2ZxeHdnLbMO8uEotafp3fyTmGZi4XDoOgGk3qACQ5zKNyaJE2Gkcfj4elnt/Fk9+aOGUd/Vt+vHm/8bIXXpk805Xlt+gQbP1sxLeMGXyxOSE1xxtZTkWNq1zi+pBhEgnA78MXmawZCi4vRPYeaIKr0M12YIWS4HErOM3o+cUte07wyQJQZ5mKBWxZTEO4NdrKjsmb4e+m1ybmoHIDYy7Z5QGVil8pYcmfLkpiG0rq6ujpqHF0pXqseH/3165b5jGlXiyuW+dyQGTZzbS+QVyP41Jrre1DJ1QpVvEn6J1p1vzW6uBvO68pV3OI21zHW0xzO01zzLuqvuNqr8taf1+W37FujPLV26+Vw0EE1tDlEhhyTQZPwppN+07X02ri405H5eNvJbNdXF7K6qNN+nliNATSOq7txdKHDyscY7rKsyyR/C3pp0qdN/7Q6nMq3O9eNYSqneWQVBra4fj5HPhypM4o0Amzty5FJ55pSXJEeYjAdYU48RcL9SvoUp8PPs8MsTT3AHnVfgxdoJ2PhWZ7zdrPFuxti+0DZzWLssHkdDlhuvu7q6uL7zwR54IH1XFr+nKXFv7dRvU4bRlWpVGwpf15JkPFH2O7XzkPJimt7hlBaf3pTF8iTIsOJappPGagtzEHdm1Qos5QdJz/sZq9MimgwRUgP6S0lYUrJ2VxvJIAPo6crxxkVgzfLqp4cU0Hd1V59Qg8wktX7XA0zzhBqq28pptK49KrlmAoOkY/N17ed7GcyaPhispUhx6RSCW+Og/KCIc1JRxbj7ZrGvrY7F+zbcF9nu+Nor8NK2FnzljrVZWhXzenGhNs+2M0ds3nrVL7VuW513znPo1bIqwuWaT5/u56eHJNKitB9EIYUhEaq+4Rmn+eiqadHZWLXLDtizWm9sbNaGK6wzKGwFloba9NrbWkYlUol/vpBlhs3rvNk92Z6ep9qrwVg3f9qb7gdO/umZT5jmrGMNRXPhEeL8xvDY+khC09NhJGqe1o7zqs53WiKsL3qyoszEs6RP19rq3ZsQF0gb5CjZzilLZhW100IhfuZVHQvR1oz8HyO9b9NRjX2xQbHvjWTGR6CpsXZIEedZ8xClnCcUX+KM2k3MgQYPaK3ZyKfrY7AZrydaeqri7lgqgdbHdnU6ehZdCuXvQ5bq6vSjyFI6qEil/PIfO5U2nWet83j0epct77vHOdR3fjZefXA5+93lqdlAowmO2GIC8K9R9W42XmKLd5tTDTcA4vKbk6HDzPmt6/n9PABeo/sA4sN2U6YGkalUolz753l0vLnPNm9maef3UZXV/s/kr3p69rvA8z9I2uZz5j22NdufnfB8BRsjPOrCQaH9SfnwjyjFSX6+9t8CtMW5Vq4ptnYMm6+rG2WtLreQDjO6PkUGSAzu0Ao3LjguqynU5xPMMWMyZO8hb47To5PGr/Q7XRkNd5usOyrHXZ6aENH/jhzhU7r1USHLVHpxzw+pYUv6bb02cHygO394nivGcYvGSGj2LzQ0RfAl06ZGLI5zqQhFA4A/fga56O6QJ5+tlrN0744c3XeVkG4zwgf5lBYZbFuDdM2XFe9SsH9LKr7ec7wZhqgb7jex5i/eUO2W0zfSuukUQRw8KWDcFMLpxUp8uLxKG99eKqa/taHp3jxeJQiWvis6783efWlg+03eD5H3h/QjCD1bTLVRT3C9nDK4FrXjn3+gG406d4NADXBVLr2dGzcVFr35aWXawqTWV03JcD28AJTSoIzxBkxLpiW9f+IkN9l/Q59qyfH5HCKUKwF48tKlnSCSVVvx1EGw54M3UNQL5+NjizH2wmLvrakL5d0os5b1mG78uheIRftO84d23lrNR6tz3XrvDbzqFX8cUbCKaJ1+5a0sN9kX6Vubb+R8Y3ZjDJusTfJQHiGudhCQ92CsIZJzxreQpvldNpPb592vMe7jQl1J4f0UFnlzbVe/8u8k91n2ITd/oZrI01/CeLxeHj0sccBOmIUVXgk/x++euphAG6WbnLy4wwnPzZ5HiqV+fY/b/EnAsJxRpUBBr3j4I8QMix+oeQMZ7wD9CjauS82z1wYIMJ0dpzBoIeeYdCeHOddPL1XytXqJDzDUtL6uhm+WByfdwiSZcD4qq91PSPZGfKGvoSSVm8CtdY3X+xEi18YgSZZCHqYrGvHSYYAPvUFery5al8a5bPUkc14V0Ijk8ZLwSG2FiI2fW13LtjRiTpvXYfu6zLoLTzDkst7xHnuNM8V47w1L29fxrxfjfeLUUare62h3wQYzc7ga8pTI5Qs46vMPYO8o0cihjzzfBI05PGPM5d1fvDwxeaZVj0MBmEpG3fMLwj3NH2LTHi72aOf7kguO4bMGqmE2t4BtA3Z23jOu79an1ss/xKkXC7j8Xhak8qBn45EWOl7hNJDD1jmWffl17w5dqSj7Qp3khRRbwJfdr4F46qdMu2SIupNsf22hgJXgzupQ8EWNcFgcJy8bjjKeAirifwliDOu/xKk00YRwNGpFN+7ABsuXOUbX13XLhZLdP37ejXPo998uOPtCoIg3DGqe8bEKBKEe5GmUNrt5rf7/wDAK78a49MP8jz44Hqe6N7MhZuXueZ/lPK6zoTuBMGcCNMF+X0YQRAEwRzLUNpqsDf6Yzb0f4ff7/3daosiCIIgCPc8EkpzpjGUdlcZRoIgCIIgdA4xjJxxvcdIEARBEAThfkMMI0EQBEEQBB0xjARBEARBEHTEMBIEQRAEQdD5P9nJ+EEfNaspAAAAAElFTkSuQmCC[/img]

общая загрузка CPU 5-8%
В итоге:
Ваш тест CPU как слону дробина.
-------------------  
 
для особо тупых
----------------
запустил Ваш тест на боевом квике
------------------
вот результаты:

это  n =5000000

это n=0

Ну и кто кого грузит?
 
Цитата
nikolz написал:
запустил Ваш тест на боевом квике
------------------
вот результаты:

Там колбеки-то были? Сравнивать имеет смысл при наличии колбеков.
Цитата
Старатель написал:
Нагрузка на CPU пропорциональна количеству любых объявленных переменных [...] и количеству колбеков, получаемых скриптом.

Скрипт:
Скрытый текст


Результаты в боевом QUIK 9.3.3.3

В утреннюю сессию (~ 9 ч. МСК)

1. n = 0: 18233; 202/сек
Скрытый текст


2. n = 1000000: 19444; 215/сек
Скрытый текст


3. n = 3000000: 18127; 200/сек
Скрытый текст


В дневную сессию (~ 10 ч. МСК)

4. n = 0: 54455; 605/сек
Скрытый текст


5. n = 1000000: 45956; 510/сек
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
nikolz,
Цитата
Ну и кто кого грузит?
Старатель, грузит процессор. Работающих скриптов писать не умеет, так что забивает его всякой хернёй, дабы разработчики изуродовали софт по его идиотским пожеланиям, и у всех остальных тоже всё бы рухнуло. А то ему абыдна. :smile:  
 
1. Из названия данной ветки, наверное, можно понять, что в ней не обсуждается оптимальное построение торговых роботов на чистом Qlua с учетом «кривизны» реализации Qlua. В ней обсуждается аномальное поведение QLua в некоторых конкретных случаях, приведенных пользователями.
Разработчик QUIK мог бы либо объяснить, либо устранить обсуждаемые ситуации, но этого не делается.
----------------------------------
2. Где содержательный ответ разработчика QUIK на мое предложение: не «дергать» мусорщик в колбеках, представленное в  сообщении 167 данной ветки?
 В последней версии QUIK 9.3.3.3 от 08.02.22, в колбеках, мусорщик продолжает (как это было и в предыдущей версии) отключаться, а затем включаться.
-----
  Для того, чтобы мое предложение было более понятно, приведу код теста, в котором демонстрируется разница между вариантом с «дерганием» мусорщика в колбеках и вариантом, когда этого «дергания» нет.  Параметры теста: 1) n - количество переменных используемых в тесте; 2) for_OnParam – нагрузка в колбеке; 3) N – количество циклов моделирования вызова колбеков.
 Разница затрат процессорного времени в вариантах, полученная в тесте нехилая: для параметров теста: n = 10000, for_OnParam = 10, N =10000 предложенный мной вариант в ~25 раз эффективнее чем с «дерганием» мусорщика.  Причем в варианте с дерганием мусорщика в колбеках, как описывает Старатель, длительность обработки колбеков существенно зависит от количества переменных, используемых в тесте (n).
  Тест выполняется без подключения к серверу, но в нем моделируются два обсуждаемых варианта. Мне не известен код QLua и поэтому, возможно, что-то мною упущено из вида, но если у разработчика QUIK есть вопросы к тесту, то я постараюсь на них ответить и задать свои. Некоторые пояснения представлены в комментариях кода теста.

  Код теста:
Код
message (' !!! Начало теста  ')
---  Параметры теста  ---
local n = 10000  --  количество переменных используемых в тесте
local for_OnParam = 10  --- Цикл нагрузки в OnParam  ---
local N = 10000  --- Цикл моделирования вызова колбеков ---
------
for i = 1, n do
  _G["f"..i] = i               -- function () end
end
------------

function OnParam(p1, p2)
    local str 
    for i = 1, for_OnParam do   --- нагрузка 
        str ='fiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii  gggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg   шшшшшшшшшшшшшшшшшшшш' .. i
   end
end
-----
message ('Область основного потока QUIK. isrunning  = ' .. tostring(collectgarbage ("isrunning")))
--------
IsRun = true
function main()
    local J
    local OnParam_begin   
   message ('Область main  isrunning = ' .. tostring(collectgarbage ("isrunning")))
---[[
    ------------------------
   --  Фрагмент моделирования обработки колбеков без дергания мусорщика 
    local T = os.clock() * 1000
    for i = 1, N do 
      OnParam ()
   end
   message ('Область main  isrunning после цикла вызова OnParam без дергания мусорщика ' .. tostring(collectgarbage ("isrunning")) .. '.  Длительность цикла: ' .. os.clock() * 1000 - T)
   ------------------------
   --  Фрагмент моделирования обработки колбеков с дерганием мусорщика 
   --               !! Если у разработчика QUIK есть замечания, напишите комментарий.
   T = os.clock() * 1000
    for i = 1, N do 
       collectgarbage ("stop") 
      OnParam ()
      collectgarbage ("step") 
      collectgarbage ("restart")  
   end
   message ('Область main  isrunning после цикла вызова OnParam с дерганием мусорщика ' .. tostring(collectgarbage ("isrunning")) .. '.  Длительность цикла: ' .. os.clock() * 1000 - T)
    ------------------------------------------------
--]]   
    while IsRun do 
      -----
        sleep(1000)  
    end
    ------------------
end   
   
function OnStop()
     IsRun = false
    return 10000   
end

-----------------------------------------

    3. Выкладываю памятку для поддержки, используемую на моих проектах. Вдруг, кому то, из читающих данную ветку, она покажется интересной.
  ----
 Памятка короткая и потому привожу ее текст полностью.

                                                        Памятка по работе поддержки с пользователями проекта
1. Пользователи являются ценнейшим ресурсом любого проекта, правильное управление которым существенно определяет успех проекта. Фактически это внештатные бесплатные отладчики проекта. Поэтому к ним следует относиться очень внимательно и доброжелательно. За найденные ими ошибки в проекте или предложения, улучшающие проект, их следует благодарить. К ошибкам, совершаемые ими, относиться спокойно и давать четкие разъяснения таким образом, чтобы не отбивать желания повторного обращения.
2. При работе с пользователями, как правило (через некоторое время),  можно выделить следующие группы пользователей:
  1) суперпользователи;   эта наиболее ценная для проекта группа пользователей, хорошо разбирающаяся в проекте, предлагающая ценные решения и конструктивно взаимодействующая с поддержкой проекта по его отладке;  как правило, это группа небольшая и поддержке проекта следует обращать на ее особое внимание, выделяя для общения с ней своих наиболее квалифицированных сотрудников, а также ключевых разработчиков проекта;
  2) ключевые пользователи; это следующая, по ценности для проекта,  группа пользователей, на работу с которой следует уделять повышенное внимание со стороны поддержки проекта;
  3) пользователи;
  4) тролли и хамы;   эта группа, кроме того, что засоряет каналы коммуникации, наносит имиджевый урон проекту;   поэтому ее следует блокировать.

Дополнительно.
При общении с пользователями, надо исходить из того, что:
1) пользователь имеет право на ошибки;
2) на любую ошибку пользователя, диагностируемую в программе проекта, должна выдаваться понятная ему диагностика;
3) любое «падение (зацикливание, блокировка, неожиданное завершение)» программы проекта, является ошибкой разработчика программы проекта;
4) параметры производительности программ проекта важны для пользователей (а в некоторых проектах очень) и являются критериями оценки успешности проекта, наряду  со стабильностью и всеми остальными критериями оценки проекта.
 
Daniil Pozdnyakov, по сообщению #179 есть вопросы? Нужно пояснить, что делает скрипт?

После заказа обезличенных сделок скрипт замеряет время получения первых 200000 сделок. После этого скрипт выдаёт замеренное время и отключается.
Тест проводится 4 раза:
1) с созданием локальной переменной, содержащей массив нулевого размера
2) с созданием локальной переменной, содержащей двумерный массив 100x1000
3) с подключением библиотеки socket
4) с подключением библиотеки iuplua

Предполагается, что во всех 4-х тестах время работы скрипта должно быть одинаковым, поскольку колбек OnAllTrade во всех тестах выполняет одну и ту же работу: OnAllTrade содержит только три простых оператора, они не должны существенно влиять на время работы функции.
В действительности же время работы скрипта много больше в тестах 2, 3, 4 по сравнению с тестом 1.
Выводы, вытекающие из теста я неоднократно приводил в этой теме.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
TGB написал:
приведу код теста, в котором демонстрируется разница между вариантом с «дерганием» мусорщика в колбеках и вариантом, когда этого «дергания» нет
Попытку раскопать истину поддерживаю. Но зачем 'step' в цикле? Надо просто отключение-запуск и тогда будет примерно аналог того, что видим в коде арки. И вот насколько оверхед будет похож на оверхед в тестах Старателя, настолько можно будет предполагать, что дело именно в этом. А так получается, что тест доказывает, что сборка мусора занимает какой-то ресурс. Все это и без теста знали.
 
Цитата
Anton написал:
Но зачем 'step' в цикле? Надо просто отключение-запуск и тогда будет примерно аналог того, что видим в коде арки. И вот насколько оверхед будет похож на оверхед в тестах Старателя, настолько можно будет предполагать, что дело именно в этом.
  Вы попробуйте убрать  'step' и увидите как растет память используемая тестом. Пусть разработчик QUIK напишет, что 'step' не используется и как при этом не "распухает" память скрипта.

Цитата
Anton написал:
А так получается, что тест доказывает, что сборка мусора занимает какой-то ресурс. Все это и без теста знали.
  Я в своем предыдущем комментарии не рассказываю о том, что сборка мусора занимает какой-то ресурс. В тесте показано (при конкретных параметрах), что «дергание» мусорщика в колбеках может увеличивать расход процессорного времени в 25 раз по сравнении с вариантом когда мусорщик не дергается.
 
Вот другой тест, без лишних предположений.
Код
function OnParam(cls, sec)
   local str = cls or '' .. sec or ''
end

function main()

   message('TEST running, wait a bit')

   sleep(1000)

   local t1 = os.clock() * 1000
   for i = 1, 1000000 do
      OnParam('TQBR', 'SBER')
   end
   t1 = os.clock() * 1000 - t1

   local t2 = os.clock() * 1000
   for i = 1, 1000000 do
      collectgarbage('stop')
      OnParam('TQBR', 'SBER')
      collectgarbage('restart')
   end
   t2 = os.clock() * 1000 - t2

   for i = 1, 1000000 do
      _G['var' .. i] = { _ = i}
   end

   local t3 = os.clock() * 1000
   for i = 1, 1000000 do
      OnParam('TQBR', 'SBER')
   end
   t3 = os.clock() * 1000 - t3

   local t4 = os.clock() * 1000
   for i = 1, 1000000 do
      collectgarbage('stop')
      OnParam('TQBR', 'SBER')
      collectgarbage('restart')
   end
   t4 = os.clock() * 1000 - t4

   message('TEST RESULT:' ..
      '\n  gc always on, no globals:   ' .. t1 ..
      '\n  gc stopped, no globals:     ' .. t2 ..
      '\n  gc always on, many globals: ' .. t3 ..
      '\n  gc stopped, many globals:   ' .. t4)

end





Вывод: просто отключение/включение сборщика увеличивает оверхед на вызов в 4 и более раз, шаг тут не нужен. Довод "тогда почему память не растет" может иметь тысячу и один ответ, сомневаюсь, что сейчас арка побежит рассказывать о своих технических решениях.
 
Цитата
Anton написал:
шаг тут не нужен.
  Вы обратили внимание на то, как меняется память при запуске вашего теста: до ~ 150 000 кб в конце теста.?
 
Цитата
TGB написал:
Вы обратили внимание на то, как меняется память при запуске вашего теста: до ~ 150 000 кб в конце теста.?
Конечно. Поскольку я своим глазам доверяю (а шага сборки после колбека я в упор не углядел), то я склонен считать,что это к делу отношения не имеет. Квик как-то там прибирается и молодец и флаг ему в руки. Как показывает тест выше, достаточно выключения/включения сборки, чтобы воспроизвести наблюдаемое поведение. Но это еще не все. Эти вызовы - сишные, поэтому их надо сравнить с просто пустыми сишными вызовами. Наиболее близко к этому - вызвать isConnected. И, чтобы два раза не вставать, сравним еще со случаем форсированного переключения потока в тех же местах. Тест и результат ниже. Как видите, дополнительная нагрузка на вызов от приостановки сборщика находится где-то между двумя пустыми сишными вызовами и двумя переключениями потока и не зависит от числа глобальных переменных. Поэтому, я считаю, вопрос об отключении сборщика (мной же поднятый) можно опустить обратно, это здесь влияет мало. Обнаруженная Старателем зависимость оверхеда от числа объявленных переменных растет откуда-то из другого места. Возможно, тоже как-то со сборкой связанного, но не так прямолинейно.
Код
local run = true
local nnn = 5000000

function OnStop()
   run = false
end

function OnParam(cls, sec)
   local str = cls or '' .. sec or ''
end

function main()

   message('TEST running, wait a bit')

   sleep(1000)

   local t1 = os.clock() * 1000
   for i = 1, nnn do
      OnParam('TQBR', 'SBER')
   end
   t1 = os.clock() * 1000 - t1

   local t2 = os.clock() * 1000
   for i = 1, nnn do
      collectgarbage('stop')
      OnParam('TQBR', 'SBER')
      collectgarbage('restart')
   end
   t2 = os.clock() * 1000 - t2

   local t2x = os.clock() * 1000
   for i = 1, nnn do
      local _ = isConnected()
      OnParam('TQBR', 'SBER')
      _ = isConnected()
   end
   t2x = os.clock() * 1000 - t2x

   local t2y = os.clock() * 1000
   for i = 1, nnn do
      sleep(0)
      OnParam('TQBR', 'SBER')
      sleep(0)
   end
   t2y = os.clock() * 1000 - t2y

   for i = 1, 1000000 do
      _G['var' .. i] = { _ = i}
   end

   local t3 = os.clock() * 1000
   for i = 1, nnn do
      OnParam('TQBR', 'SBER')
   end
   t3 = os.clock() * 1000 - t3

   local t3x = os.clock() * 1000
   for i = 1, nnn do
      local _ = isConnected()
      OnParam('TQBR', 'SBER')
      _ = isConnected()
   end
   t3x = os.clock() * 1000 - t3x

   local t3y = os.clock() * 1000
   for i = 1, nnn do
      sleep(0)
      OnParam('TQBR', 'SBER')
      sleep(0)
   end
   t3y = os.clock() * 1000 - t3y


   local t4 = os.clock() * 1000
   for i = 1, nnn do
      collectgarbage('stop')
      OnParam('TQBR', 'SBER')
      collectgarbage('restart')
   end
   t4 = os.clock() * 1000 - t4

   message('TEST RESULT:' ..
      '\n  gc always on, no globals:            ' .. t1 ..
      '\n  gc stopped, no globals:              ' .. t2 ..
      '\n  gc always on, no globals, c-calls:   ' .. t2x ..
      '\n  gc always on, no globals, sleeps:    ' .. t2y ..
      '\n  gc always on, many globals:          ' .. t3 ..
      '\n  gc always on, many globals, c-calls: ' .. t3x ..
      '\n  gc always on, many globals, sleeps:  ' .. t3y ..
      '\n  gc stopped, many globals:            ' .. t4)

end

 
Цитата
Anton написал:
Квик как-то там прибирается и молодец и флаг ему в руки.
 И не тратит на это никаких вычислительных ресурсов?
 
Цитата
TGB написал:
И не тратит на это никаких вычислительных ресурсов?
Тратит, но не на каждом колбеке. По моим наблюдениям, не чаще раза в секунду, если его не подталкивать.
 
Anton, Сборщик-то влияет, может, и мало, но у меня вопрос: а какого хрена он вообще тут "влияет"? Если я заказал память, это МОЯ память! Если я ему куда-то кинул nil - другое дело, чисти на здоровье - даже искать ничего не надо. А если не кинул - тем более ничего делать не надо! Какая с него польза, кроме оверхеда?

Теперь тесты: убей, не пойму, что тут вообще проверяется. Вижу, в цикле вызывается OnParam, но ведь это же, блин, прерывание! Прерывания на то и существуют, чтобы прерывать, а здесь обработчик вызывается явно из того самого кода, который он должен прерывать. И что дают эти миллионные циклы? Кто вообще может гарантировать, что умный интерпретатор не заменит конструкцию:
for i = 1, 1000000 do OnParam('TQBR', 'SBER');end
ОДНИМ вызовом? Мне доводилось видеть такие "оптимизирующие" компиляторы. И кому здесь вообще нужна скорость? Надёжность, надёжность и ещё раз надёжность! А она практически на нуле. И продолжает падать, хотя дальше падать некуда. А память? Ну кому нужна эта память? У меня она постоянно болтается в диапазоне 5-10 мегов, иногда чуть больше, иногда чуть меньше. Памяти тоже хоть жопой жуй! Ни один программист (и все местные тестировщики, вместе взятые) в реальных скриптах никогда не смогут окучить и сотой доли переменных, которые они здесь тестируют. НУ НА КОЙ ВСЁ ТО НАДО?!
 
Цитата
Владимир написал:
Какая с него польза, кроме оверхеда?
Мне, выходит, сейчас придется выступить в роли адвоката сборщиков мусора, кои я сам терпеть не люблю ) Не, не буду )

Цитата
Владимир написал:
в цикле вызывается OnParam
Переименуйте мысленно, квик и подключен быть не должен, чтобы это все прогнать.

Цитата
Владимир написал:
Кто вообще может гарантировать, что умный интерпретатор не заменит конструкцию
Я могу гарантировать, что квик до 9.3.3 включительно не заменит. Большего нам и не требуется. А теперь собственно

Цитата
Владимир написал:
что тут вообще проверяется
Пошла волна, что, мол, все беды от того, что арка перед вызовом колбека отключает сборку мусора, а после - включает. Наблюдение мое было, но вот уже на это списали все беды квика и айти отрасли в целом. Что наблюдать печально, а мои призывы охладить этосамое игнорируются. Вот пришлось показать, что не все беды от этого, и вообще не от этого, и что тупой isConnected из одной инструкции дает почти тот же оверхед, что и новоназначенные враги квика. А миллионные циклы - чтобы вся эта шняга хоть бы сотню миллисекунд длилась, а то ж ее никаким таймером не выловишь.
Страницы: Пред. 1 2 3 4 5 6 След.
Читают тему
Наверх