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

Страницы: 1 2 3 4 След.
RSS
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
Демонстрационный скрипт:
Скрытый текст

QUIK 9.3.1.11, Lua 5.4
Открыто, как минимум одно окно: стакан ликвидного инструмента.
Конечно, никто не запускает скрипты с тысячами функций, но при нескольких запущенных скриптах с десятками функций при высокой активности на бирже получаем нихилую загрузку CPU.

ЗЫ: У кого "один скрипт на все случаи жизни" с парой функций, может игнорировать эту тему.
Без флуда!
Надо делать так, как надо. А как не надо - делать не надо.
 
Даже не так.
Нагрузка на CPU пропорциональна количеству любых объявленных переменных (глобальных ?), в т.ч. функций (не обязательно выполняемых, а просто объявленных) в скрипте и/или подключаемых модулях и количеству колбеков, получаемых скриптом.
Когда в QUIK открыты одна или несколько ТТТ с большим количеством бумаг, стаканы, ТОС, то скрипты, в которых есть колбеки по событиям из этих таблиц, при высокой активности торгов сильно тупят.
Надо делать так, как надо. А как не надо - делать не надо.
 
Думаю, что очень актуальный вопрос поднят. Спасибо топик-стартеру за демонстрацию проблемы. От разработчиков терминала ждём пояснений.
 
Цитата
Старатель написал:
Демонстрационный скрипт:
    Скрытый текст        
Код
   local  n  =   50000 
 for  i  =   1 , n  do 
  _G[ "f"  .. i]  =   function  ()  end 
 end 

 local  class  =   "SPBFUT" 
 local  sec  =   "SiZ1" 
 local  param  =  {"BIDDEPTHT",  "OFFERDEPTHT" }

 local  run  =   true 
 function   OnStop ()
  run  =   nil 
 end 

 function   main ()
  assert( Subscribe_Level_II_Quotes (class, sec))
   for  i  =   1 ,  # param  do 
    ParamRequest(class, sec, param[i])
   end 
   while  run  do   sleep ( 500 )  end 
   Unsubscribe_Level_II_Quotes (class, sec)
   for  i  =   1 ,  # param  do 
    CancelParamRequest(class, sec, param[i])
   end 
 end 

 function   OnQuote (class_code, sec_code)  end 
 function   OnParam (class_code, sec_code)  end 
 function   OnAllTrade (alltrade)  end   

QUIK 9.3.1.11, Lua 5.4
Открыто, как минимум одно окно: стакан ликвидного инструмента.
Конечно, никто не запускает скрипты с тысячами функций, но при нескольких запущенных скриптах с десятками функций при высокой активности на бирже получаем нихилую загрузку CPU.

ЗЫ: У кого "один скрипт на все случаи жизни" с парой функций, может игнорировать эту тему.
Без флуда!
Согласен, что всегда можно написать скрипт, который загрузит бессмысленными вычислениями любой супер компьютер.
Но вопрос лишь в том, виноват ли в этом скрипт?
----------------------------------
Пару слов по существу проблемы (это мой опыт решения данной проблемы. При этом  даже нейронная сеть на ХР c одним ядром загружает CPU не более , чем на 30%.)
-------------------
1) Снизить загрузку процессора можно простым сворачиванием окон квика.
2) Если в скрипте и его функциях используются циклы в историю данных, то это очень плохой скрипт.
3)  Язык луа не предназначен для сложных вычислений (обработка больших массивов данных) поэтому используйте API C for Lua.
4)  Вызов кобеков QLUA реализуйте в одном скрипте для любого количества роботов и скриптов, в которых используете данные колбеков
5)  Не надо лазить постоянно в архив терминала, используйте таблицы луа для хранения получаемых с биржи и от брокера данных .
 
Владимир, nikolz,
господа флудеры, в демонстрационном скрипте нет никаких вычислений от слова совсем. Колбеки, вызываемые скриптом, пустые и не должны были бы оказывать на CPU абсолютно никакого влияния.
Не надо искать подвох в скрипте, он написан лишь с одной целью: продемонстрировать в первую очередь разработчикам Арки существенный баг в организации вызовов колбеков скриптами. По факту получается, что время, затрачиваемое на вызов колбека, существенно больше, чем выполнение кода в колбеке.
C Владимиром согласен в одном: "математика есть полное говно". Вот только это не моя математика, а квиковская, в котором есть прямая зависимость между количеством объявленных переменных и производительностью. Я, конечно, догадываюсь, в чём тут дело. Но так быть не должно.
Предлагаю вам воздержаться от засирания темы. Хотя кому я это пишу...
Надо делать так, как надо. А как не надо - делать не надо.
 
Для уточнения: о каких функциях речь? Любых пользовательских, или только о подписанных колбеках и функциях qlua?

Не скажу, что у меня тысячи функций, но я предпочитаю разбивать код. Поэтому у меня их достаточно много. Какой-то существенной нагрузки не наблюдаю.
 
А если колбеки убрать станет лучше? И какие именно колбеки убрать, от убирания которых становится лучше?
 
Старатель, Мы не слепые, господин флудер. В нормальных скриптах, не ставящих целью засрать процессор (в моём, например) нет НИ ОДНОЙ из этих дурацких 50000 "функций", НИ ОДНОГО вызова assert, НИ ОДНОГО Subscribe_Level_II_Quotes, НИ ОДНОГО ParamRequest, НИ ОДНОГО  Unsubscribe_Level_II_Quotes, НИ ОДНОГО CancelParamRequest, НИ ОДНОГО OnQuote, НИ ОДНОГО OnParam, НИ ОДНОГОOnAllTrade. Из всех присутствующих в "демонстрационном скрипте" у меня есть только main, да OnStop. И (поэтому!) у меня нет ни малейших проблем с "организацей вызовов колбеков скриптами".

Это Вы сами додумались, что "колбеки, вызываемые скриптом, пустые и не должны были бы оказывать на CPU абсолютно никакого влияния" или подсказал кто?

Квиковская математика, разумеется, говно (как и сам язык), но даже она вполне способна организовать полноценную торговлю - настолько, что искать что-либо лучшее я просто не хочу.
 
Я про приведённый скрипт.
А если main убрать - станет лучше?
В целом в самом деле не понятно по каким критериям вы говорите, что есть загрузка процессора.
А совсем этот скрипт остановить - какая загрузка? А запустить скрипт какая загрузка? И сколько ядер у вас процессор, чтобы отмасштабировать цифры.
Потому как "большая загрузка" - не понятная вводная. Надо бы знать что такое небольшая для вас и наоборот что большая, в цифрах. Чтобы масштаб проблемы был понятен.

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

Просьба к техподдержке передать информацию разработчикам и написать соответствующее сообщение в этой теме.



 
 
Цитата
Nikolay написал:
о каких функциях речь? Любых пользовательских, или только о подписанных колбеках и функциях qlua?
Nikolay, В сообщении #2 уточнение: речь идёт о любых объявленных переменных. Возможно глобальных, но это не точно.
Вы можете заменить блок создания переменных таким образом:
Код
_G["f"..i] = i
Естественно, в моменты низкой активности торгов, а тем более на демке, влияние на загрузку будет незначительно. Если только не увеличить количество переменных и/или скриптов. Можно ещё в скрипт добавить подписку на другие ликвидные инструменты, чтобы получать больше событий.

Цитата
swerg написал:
А если колбеки убрать станет лучше?
Станет.

Цитата
swerg написал:
какие именно колбеки убрать, от убирания которых становится лучше?
Очевидно, те, которые вызываются чаще.

Цитата
swerg написал:
А если main убрать - станет лучше?
Совсем убрать? Скрипт остановится.

Цитата
swerg написал:
Чтобы масштаб проблемы был понятен.
swerg, сравните загрузку CPU при запущенном(ых) скрипте(ах) с блоком создания переменных
Код
_G["f"..i] = function () end
и без него. При открытых окнах (стаканы, ТТТ, ТОС) и при закрытии всех окон в квике.

Цитата
swerg написал:
не особо слышно чтобы тормозил от колбеков
swerg, А кто догадается, что тормоза именно от вызова колбеков? Не от выполнения кода внутри колбека, а просто от вызова.
В этой теме посмотрите #4 и #5 сообщения:
https://forum.quik.ru/messages/forum10/message59837/topic6874/#message59837
Не факт, что там именно эта проблема. Но это легко проверить:
1) автору достаточно добавить в начало каждого колбека do return end и проверить загрузку
2) переименовать каждый колбек как-то так OnQuote -> OnQuote_ и снова проверить загрузку
Если в 1-м случае нагрузка не изменится, а во 2-м уменьшится, то это - обсуждаемая здесь проблема.
Надо делать так, как надо. А как не надо - делать не надо.
 
Только сейчас разглядел создание 50 тыс глобальных переменных
Ну и чего вы хотите? функция в ЛУА - это просто глобальная переменная типа "функция".
Чтобы функцию вызвать - ее надо найти, на это, очевидно, уходит время.
Давайте десятки миллионов глобальных переменных создадим и будем требовать оптимизации. Зачем? кому интересен этот сценарий??

Уверен, если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить. Т.е. это такое вполне понятное свойство интерптетатора Луа.
Просто не надо заводить десятки тысяч глобальных переменных.

Так что в данном случае я согласен с первыми высказавшимися "флудерам". Завалить можно любую систему. Вот только не со всеми "завалами" есть смысл разбираться, ибо некоторые из них (как здесь) будут сугубо не жизненные.
 
Цитата
swerg написал:
Только сейчас разглядел создание 50 тыс глобальных переменных
Это количество было написано для саппорта, который проводит "нагрузочное тестирование" на демке, где количество событий на два порядка меньше, чем в реале. Чтоб потом не было разговоров, что все летает.
На бою, естественно, и рядом нет тысячи переменных.

Конечно, я не учёл фактор теоретиков-флудеров.
Цитата
swerg написал:
если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить.
Пруф в студию.
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель,
Цитата
На бою, естественно, и рядом нет тысячи переменных.
У кого нет, а у кого и есть. Когда я тестировал данные от Финама, опрашивалось более 20000 тикеров два раза в секунду. И ничего, Квик справлялся.
Цитата
Пруф в студию.
Пруф уже в студии, и написан лично Вами. В частности, выделен мною как "особенно понравившийся". А вообще включите мозги: ЕСЛИ интерпретатору подсунули десятки тысяч переменных, ТО при обращении к любой из них он должен среди всей этой навозной кучи как-то НАЙТИ нужную.
 
Цитата
swerg написал:
Чтобы функцию вызвать - ее надо найти, на это, очевидно, уходит время.
У луа глобальные функции/переменные находятся в таблице, а поиск в таблице луа заявлен как O(1), не должно бы по идее влиять, по крайней мере заметно влиять. Квик ничего не выдумывает, берет колбек из скрипта через lua_getglobal, так что вопрос интересный, как оно так вышло. Например, может тормозить поиск не в таблице по ключу, а самого ключа (строки), там вроде какой-то кэш строк есть, и при числе именованных переменных сильно больше его размера можем получать постоянный кэшмисс. А можем и не получать, рыть надо.
 
Цитата
Anton написал:
вопрос интересный, как оно так вышло
Сложился паззл. Когда в девятой версии смотрел "чего нового" в отладчике, увидел, что после каждого колбека lua_gc добавили. Не обратил внимания только, полный или шаг. Вот оно собсна и есть, пропорционально количеству потенциального мусора. Насколько это критично в реальном применении, а не в модельном примере, вопрос открытый. Сама по себе идея синхронно прибраться в основном потоке выглядит хорошей, чутка пошаманить с частотой этого действа разве.
 
Anton, Мало ли что у них заявлено! К тому же, это наверняка "в среднем", а не в худшем случае. Да и число переменных они тестировали дай бог в пару сотен (если вообще тестировали).
Цитата
рыть надо
А зачем?
 
Цитата
Владимир написал:
А зачем?
Башку чем-нибудь околокодовым забить, пока заняться нечем.

Цитата
Владимир написал:
наверняка "в среднем", а не в худшем случае
Хэш-таблица плюс хвост из новодобавленного с периодическим рехэшем, в итоге амортизированное O(1). Так-то, если слишком рано в бесконечные не уходить, сложность хэш-таблицы O(N/M), где M - число входов, в (самом) худшем просто считаем N/M->N и получаем O(N), типа такая вырожденная хэш-таблица с одним входом.
 
Пока биржа не тогует, решил проверить одну идею на демке.
Junior, настройки по-умолчанию.
Открыл три окна: ТОС, системные сообщения и доступные скрипты. В ТОС добавил неторговый класс SMS-оповещения, чтобы не мешала измерениям.

Далее запустил одновременно три копии скрипта:
Скрытый текст

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

Далее повторяю процедуру с f(150). Время работы скриптов выросло на 25%.
С r(150) - на 80%-90%.
При подключении socket время также увеличилось в 1,8 раза. А с iuplua в 3 раза.

Так что, дело тут не только в глобальных переменных.
Надо делать так, как надо. А как не надо - делать не надо.
 
До кучи решил ещё одну тему проверить.
swerg, то, что вы написали
Цитата
swerg написал:
если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить. Т.е. это такое вполне понятное свойство интерптетатора Луа.
- бред и не соответствует действительности: в чистом Lua время вызовов пустой функции никак не изменится даже после создания "десятков миллионов глобальных переменных". Коль ввязываетесь в спор, вы бы хоть проверяли, прежде, чем чё-то писать.
Надо делать так, как надо. А как не надо - делать не надо.
 
Даже просто создание локальной таблицы снижает производительность. Методика тестирования описана в сообщении #20

Код
local run = true
function OnStop()
  run = nil
end

local t
function OnAllTrade()
  if getNumberOf("all_trades") == 1 then
    local num = 1
    function OnAllTrade(alltrade)
      num = num + 1
      if num == 200000 then run = false end
    end
    t = os.clock()
  end
end

function main()
  local a = {}
  local n = 0
  --local n = 20000
  for i = 1, n do a[i] = i end
  while run do sleep(1) end
  if t then message(tostring(os.clock() - t)) end
end

Получается, кеширование любых данных, например для расчётов индикаторов, снижает производительность при вызовах колбеков.
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель, Создание - снижает, это нагрузка на таблицы Квика. Собственно, не на создание, а на "созерцание". Тем более, не просто таблицы, а ТОС, которая нафиг никому не нужна. Индикаторы, тоже снижают, по той же причине. А вот если не заниматься подобной фигнёй и оставить только OnTrade, да обработчики, устанавливаемые по SetTableNotificationCallback, да поставить не sleep(1), а хотя бы sleep(500), то "производительность при вызовах колбеков" не просто удовлетворительная, а почти идеальная.
 
Цитата
swerg написал:
Давайте десятки миллионов глобальных переменных создадим

А давайте, чё мелочиться!
Скрипт:
Скрытый текст

Методика тестирования описана в сообщении #20. Только в этот раз я запускал только один экземпляр скрипта.
Результаты тестирования в различных версиях QUIK при 0 и 10000000 глобальных переменных:
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель, А обращаться к этим "миллионам переменных" Пушкин будет? :wink: Вы всего лишь создали навозную кучу, но не ковырялись в ней в поисках нужной переменной.
 
Владимир, ну что за человек. Ну не понимаешь о чем тема, чё засирать её своими "умными мыслями".
Надо делать так, как надо. А как не надо - делать не надо.
 
Поправка к коду в сообщении #25: время надо фиксировать в самом колбеке. Но это не сильно влияет на итоговый результат: завышение результата на 0 - 0.5 сек.
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель, Лапуль, я прекрасно понимаю о чём тема, и в первом же своём сообщении написал: "Вся тема есть чистейший флуд на 146%".

А чуть дальше столь же русским языком написал: "ЕСЛИ интерпретатору подсунули десятки тысяч переменных, ТО при ОБРАЩЕНИИ к любой из них он должен среди всей этой навозной кучи как-то НАЙТИ нужную".
 
Цитата
Anton написал:
в девятой версии смотрел "чего нового" в отладчике, увидел, что после каждого колбека lua_gc добавили.
Anton, начиная с 9.1 добавили?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
начиная с 9.1 добавили?
Точно не 9.3, а вот 9.1 или 9.2 - не помню. Сам стенд остался, но я не там, в ближайшие дни не смогу уточнить.
 
Цитата
Anton написал:
9.1 или 9.2
Тест из сообщения #23 показывает, что с версии 9.1
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель,  если дело в этом, смена режима должна, по идее, заметно влиять, т.е. одно из в начале
Код
collectgarbage('incremental')
collectgarbage('generational')
 
Цитата
Старатель написал:
Цитата
swerg написал:
если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить.
Пруф в студию.

Для экспериментов возьмем online lua https://qlua.ru/demo/
Результаты выходят не очень стабильными, но все же проведя пару десятков экспериментов и выкинув пару экстремально отличающихся результатов, получил следующее время выполнения:
100 глобальных переменных - 1,4753 сек
100 тыс. глобальных переменных - 1,5608 сек

Да, разница не фантастически великая. Но какая-то явно есть. Разница много меньше, чем в ваших экспериментах внутри квика, это стоит отметить.

Тестовый код:
Скрытый текст
 
Цитата
Старатель написал:
v(0) -> 4.9 сек
v(10000000) -> 4.4 сек

QUIK 8.1.0.30:
v(0) -> 5.7 сек
v(10000000) -> 5.9 сек

QUIK 8.13.1.16, Lua 5.4:
v(0) -> 6.4 сек
v(10000000) -> 6.0 сек

QUIK 9.3.1.11, Lua 5.4:
v(0) -> 7.7 сек
v(10000000) -> 17.3 сек

QUIK 9.3.1.11, Lua 5.3:
v(0) -> 7.9 сек
v(10000000) -> 17.4 сек

Деградация от версии к версии определённо печалит. Хоть я и поставил бы под сомнение корректность некоторых полученных результатов (v(0) больше, чем v(10000000) ??). Но, похоже, в 9.3 точно случилось что-то.
 
Что-то вы, ребятки, не то делаете... какая-то _G, панимаш... про которую пишут, что "в новых версиях Lua вместо _G теперь _ENV"... У одного вообще без обращений, у другого к паре переменных туеву хучу раз... ВОТ ТАК в моём понимании создаются локальные переменные:

Ах, у loadstring с локальными переменными проблемы - ну, сделаем глобальной.
Код
f=true;
N=1000;
J=0;
function main()
 local i;
 for i=0,N do
  loadstring("v"..i.."="..i%100)();
 end;
 F=io.open(getScriptPath().."//TEST","w");
 for i=0,N do
  loadstring("J=v"..i)();
  F:write("i="..i.." v"..i.."="..J.."\n");
 end;
 F:close();         -- закрываем входной файл

-- while f do
--  sleep(500);
-- end;

end;

function OnStop()
 f=false;
 return 500;
end;
Ну да, и в TEST всё в порядке:
Код
i=0 v0=0
i=1 v1=1
i=2 v2=2
...
i=99 v99=99
i=100 v100=0
...
А в закомментированных строчках к ним должны бы быть протестированы обращения к этим переменным, но мне лень думать, как это делать, ибо НОРМАЛЬНАЯ у Квика производительность! НОРМАЛЬНАЯ! Не нравится "нормальная" - скажу "идеальная"! Она непригодна разве что для этой долбаной HFT, но тому нужно чесать прямиком на биржу, чтобы ловить там свои сраные сотые доли процента. Просто писать надо уметь, а не плакаться здесь в жилетку по самым идиотским "проблемам". :wink:  
 
Цитата
_sk_ написал:
Думаю, что очень актуальный вопрос поднят. Спасибо топик-стартеру за демонстрацию проблемы. От разработчиков терминала ждём пояснений.
Присоеденяюсь.
-----
 Деградация эффективности QLua показатель низкого качества реализации разработчиками QUIK встраивания Lua в QUIK. Эффективность выполнения скриптов QLua без обращения к API QUIK должна отличаться от Lua только затратами на операции lock/unlock в вызовах функций C-API QLua, а также в VM-QLua (ulock/lock) при вызове C-функций. Причем упомянутые операции в подавляющих случаях «холостые» (потоки не переключают). Все места вызова lock/unlock (ulock/lock) определены в кодах Lua разработчиком Lua.  Разработчику QUIK достаточно корректно реализовать lock/unlock, например, используя критические секции, обеспечивающие эффективную синхронизацию.
   Вопрос к поддержке: какое «ноу-хау» обеспечивает деградацию эффективности QLua новых версий?
-----
Цитата
Anton написал:
Сложился паззл. Когда в девятой версии смотрел "чего нового" в отладчике, увидел, что после каждого колбека lua_gc добавили.
 Интересное открытие (пишу без иронии).
 Вопрос к поддержке: a это зачем сделали?  Хотелось бы чтобы разработчик QUIK пояснил как додумался до этого. Какие проблемы это решает?
 
Деградация производительности мешает утром, когда происходит подключение к срочному рынку и заново приходят все обезличенные сделки с вечерней сессии. Если скрипты реагируют на соответствующие коллбэки и скриптов много, то происходят жуткие тормоза даже на современном железе. Конкретно у меня, несмотря на то, что реакция на обезличенные сделки минимальная, обезличенные сделки прогружаются минут десять с включенными скриптами и раз в 10 быстрее с выключенными. Судя по загрузке процессора (Core i7 9700K), упираемся именно в него. Уверенность в том, что в терминале есть какая-то жуткая неэффективность в этом месте, почти стопроцентная.

Убедительная просьба к техподдержке донести до разработчиков информацию по данной проблеме. Старатель предоставил описание тестового стенда, который даже на QUIK Junior демонстрирует деградацию производительности терминала в 2 раза по сравнению в более ранними версиями.
 
Цитата
swerg написал:
Деградация от версии к версии определённо печалит. Хоть я и поставил бы под сомнение корректность некоторых полученных результатов (v(0) больше, чем v(10000000) ??).
В сообщении #28 есть уточнение про погрешность.

Цитата
Anton написал:
после каждого колбека lua_gc добавили. Не обратил внимания только, полный или шаг. Вот оно собсна и есть, пропорционально количеству потенциального мусора.
Тут надо отметить, что, если в скрипте есть таблица, в которой постоянно добавляются и убираются элементы, то фактически количество элементов в таблицы будет только расти и никогда не уменьшаться.
Например, имеем таблицу активных заявок orders с ключом order_num. Когда заявка становится неактивной, убираем её: orders[order_num] = nil. Но для сборщика мусора этот элемент будет продолжать существовать со значением nil, он не сможет его очистить. Чтобы удалить элемент из таблицы, надо полностью удалить саму таблицу. Т.о., объём потенциального мусора будет только расти со временем работы скрипта.

Цитата
Anton написал:
Насколько это критично в реальном применении
У каждого своё реальное применение. Кто-то торгует только один инструмент, а другой весь рынок отслеживает. Кому-то и 200 стаканов мало. Сами понимаете, в каждом случае количество событий будет отличаться кардинально.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Anton написал:
Насколько это критично в реальном применении, а не в модельном примере, вопрос открытый.

А вот в реальном применении: загрузка CPU сегодня на открытии основной сессии в 10 ч.
Слева - QUIK 9, справа - QUIK 8 при одинаковых настройках и одинаковом количестве открытых окон. Отличие только в том, что в QUIK 8 скрипты торгуют, а в QUIK 9 режим торговли не включен, т.е. работы выполняется меньше, чем в 9.
Надо делать так, как надо. А как не надо - делать не надо.
 
А нет обманул, в QUIK 8 запущено даже на два скрипта больше - для сбора статистики.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Anton написал:
смена режима должна, по идее, заметно влиять, т.е. одно из в начале
Код
  collectgarbage( 'incremental' )
collectgarbage( 'generational' )
  

'incremental' - без видимых улучшений
'generational' на синтетическом тесте показал заметное улучшение. Что он делает?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Что он делает?
Это новый режим в 5.4, генерационная сборка (а-ля дотнет новый), типа "сначала собрать свежий мусор, если все равно много осталось - тогда шаг по всему". Раз влияние есть, то хайли лайкли нагрузку действительно дает коллектор. Думаю, поиграть с параметрами стоит, может найтись удачная конфигурация, тогда останется ее как дефолтную предложить. На память не скажу, что куда крутить, надо в доки луа лезть.
 
Ну появился он в 5.2

https://www.lua.org/wshop18/Ierusalimschy.pdf
 
В сообщении #41 опечатался.
* в QUIK 8 скрипты торгуют, а в QUIK 9 режим торговли не включен, т.е. в 9 работы выполняется меньше, чем в 8.
+ в QUIK 8 на два скрипта больше. А нагрузка - сами видите.
Надо делать так, как надо. А как не надо - делать не надо.
 
Идея построить событийную модель в основном потоке - бред изначальным. А еще про "безопасность" заливают... ДЫРЫЩИЩЕ! Поэтому я её не использую.

Например, в MQL OnTick() не блокирует МТ5 и код может выполняться бесконечно в СВОЁМ потоке - только тики пропускает.
 
Цитата
Nikolay написал:
Ну появился он в 5.2
Да, первая неудачная попытка. В 5.3 убрали за глючность, в 5.4 вроде до ума довели и вернули.
 
Интересно, почему до сих пор техподдержка никак себя не проявила в этой теме? В заголовке ведь явно указано [BUG]. Похоже, придётся специальную тему в "Пожеланиях..." создать для ускорения реакции.
 
Не баг, а фича :D
И вообще не до этих мелочей
 
Цитата
Владимир написал:
Не баг и не фича. И уж точно "не до этих мелочей". Чем меньше техподдержка будет реагировать на подобные темы, тем лучше. Квик и без того грузится чуть ли не дольше, чем операционка - это ещё хрен бы с ним. А то, что он отвисает в самых безобидных ситуациях, иногда даже без входа в Сеть - это как? А то, что вообще вылетает, причём молча - взглянешь на комп, а один из моих Квиков как корова языком слизнула. А на всякие "неизвестные исключения" или даже "unknown hard error" я уже и внимание перестал обращать: не вылетела - и ладно. И упаси меня, Господи, от новых версий!

Теперь второй вариант: какие-то придурки понаоткрывают себе всяких таблиц, графиков, стаканов, заведут немеряное количество разных переменных, подпишутся на все возможные колбеки, да ещё скулят при этом: "Повышенная загрузка CPU" - баг, панимаш! И фонтанируют своими идиотскими предложениями: то им не так, да это не этак. Ручонки кривые, а не баг! С какой радости техподдержка должна таких уродов ублажать?
Просто , КВИК- это добротная телега.
А некоторым мерещится студебекер лили даже ероплан.
Вот они на этой телеге с обрыва и прыгают.  
И потом долго по форуму пишется : '...Твою мать, ...Твою мать,... Твою мать"
 
HFT - закрытый банковский клуб и Квик там не нужен.

Для акционеров достаточно Веб-клиента.

А мы - спекулянты по фьючерсам, здесь, потому что альтернативы у Брокера нет.
 
nikolz, Ну, и на Квик, и на язык я в своё время предостаточно матерился, так что "добротной" эту телегу я бы не назвал. :smile:  Но она, по крайней мере, позволяет нормально торговать, а все эти долбаные "нововведения" лишают её этой возможности. Деньги же всё-таки, надёжность превыше всего! Любые изменения, снижающие надёжность, должны отбрасываться без рассуждений. А если не снижают - тут уже можно и выпендриваться.
Страницы: 1 2 3 4 След.
Читают тему (гостей: 1)
Наверх