После первичной установки QUIK из дистрибутива и запуске LUA скриптов по умолчанию теперь используется версия LUA 5.4.1.
Ошибка в работе функции SetUpdateCallback QLUA, приводящая к чрезмерному потреблению памяти.
Некорректное отображение значений в подсказке параметров свечи в левом верхнем углу графика.
В некоторых случаях не отображалась подсказка параметров свечи на графике.
При замене заявки снимался признак «Заявка маркет-мейкера».
Аварийное завершение работы терминала при добавлении двух криптопровайдеров.
Некорректный расчет значения поля «max» на форме ввода заявки для маржинальных инструментов при установленном признаке «Исходя только из собственных средств»
В некоторых случаях в таблице «Клиентский портфель» некорректно рассчитывался параметр «Стоимость портфеля».
В таблице «Купить/Продать» некорректно отображались дисконты по фьючерсным контрактам.
И опять в этой версии не выделены контрастно вкладки внизу. Видимо разработчики считают это мелочью и не сидят годами перед экраном. Продолжаем ломать глаза.
При большом количестве открытых окон и запущенных скриптов терминал через несколько дней после запуска потребляет много памяти и тормозит при прокачивании данных после смены даты торговой сессии. Сравниваю с 8.13, где были те же самые настройки и условия эксплуатации.
Ещё вижу повышенное использование процессора в QUIK 9.3. Не подскажет ли кто, как можно при работающем терминале понять, что именно забирает на себя ресурсы CPU? Типа какого-то профилировщика запустить?
Я могу, конечно, пытаться наугад действовать: закрыть наименее нужные окна (стаканы, ТТТ), снизить интенсивность вывода скриптами данных в таблицы, созданные QLua, но хотелось бы "не блуждать в потьмах".
Со своей стороны заметил, что есть "узкое место" с выводом данных в таблицы, созданные QLua. Как будто внутри терминала избыточная синхронизация в этом месте. Причём заголовок окна обновляется быстро, а содержимое таблиц -- медленно (при специальном нагрузочном тесте). Я уже снизил количество строк в таблицах и интенсивность вывода, но, похоже, что всё равно затык в этом месте. Для ориентира по нагрузке: в терминале открыто 45 окон (обычные и созданные QLua).
Вот пример загрузки CPU, которую process explorer выводит. При этом процессор Intel Core i7-9700K слабым не назовёшь, а загрузка ядра близка к максимуму 12.5%
function main()
local pf = getPortfolioInfoEx("SPBFUT000000","SPBFUT000nw",0) -- некорректный код счета (обязательно)
PrintDbgStr(type(pf))
PrintDbgStr(tostring(pf))
end
Рабочий квик ВТБ
В версии 9.2.3.15 и LUA 5.4 данный код вызывает ошибку ACCESS VIOLATION at address 00007FF9F3D71FB4 В версии 9.2.3.15 и LUA 5.3 падение терминала
Демо квик
В версии 9.3.1.11 и LUA 5.4
[6500] string [6500] а‹fb <- эти символы всегда разные
В версии 9.3.1.11 и LUA 5.3 ACCESS VIOLATION at address 00007FF9F057CC05
Давно уже есть такая беда - если долго не переключиться на вкладку с ТОС , то движок таблицы падает вниз
и содержимое отображается с начала сессии с 7часов. Заметил , если тыкаться через 5-10 мин , то все держится как надо. Если 30-40-50 мин , то почти наверняка движок падает. Это есть и в текущих версиях и в ранних 8....Очень достает постоянное приведение таблицы
в текущее время. А у меня много таких ТОС. Впечатление , что где-то срабатывает эдакий вредительский таймер . Посмотрите, пожалуйста, что не так. Ну и традиционное пожелание ( в стотыщный раз) выделить вкладки контрастно.
Медленная работа Рабочего места QUIK в некоторых случаях при запуске или во время работы. Некорректное построение таблицы котировок в некоторых случаях.
Ради интереса запустил QUIK 9.3.3.3 под эмулятором Wine (winehq stable 6.0.2) в виртуалке Ubuntu 21.10. Увидел, что медленно работает скрипт экспорта биржевых данных, причём та его часть, которая из тиков, накопленных за несколько часов с начала торговой сессии, в оперативной памяти формирует свечные данные. Ввода-вывода в этом фрагменте кода вообще никакого нет. Скорость в одном из замеров примерно в 10 раз медленнее, чем в случае Windows на аналогичном по скорости процессоре. Как мне кажется, это указывает на какое-то совсем тормозное место внутри терминала, которое в эмуляторе совсем проседает.
В коде в цикле по всем обезличенным сделкам есть обращение к функции getItem:
Код
for i = 0, getNumberOf("all_trades") - 1 do
local item = getItem("all_trades", i)
редкое обращение к getSecurityInfo(classCode, secCode).lot_size, результаты которого кэшируются, а в остальном идёт работа с оперативной памятью (много таблиц, представляющих собой свечные данные 1-минутного таймфрейма по всем тикерам из классов акций (Т+2) и фьючерсов (без опционов)).
Код функции, которая работает медленно, ниже.
Скрытый текст
Код
local function getSecCodeMinutes(secCodesTable)
if next(secCodesTable) == nil then
secCodesTable = nil
end
local tradeDate = getInfoParam("TRADEDATE")
local day, month, year = string.match(tradeDate, "(%d+).(%d+).(%d+)")
local yyyymmddTradeDate = year * 10000 + month * 100 + day
local lotSizes = {}
local newSecCodeMinutes = {}
for i = 0, getNumberOf("all_trades") - 1 do
local item = getItem("all_trades", i)
if item == nil then
-- очистка данных
return nil
end
-- Использование данных только за текущий торговый день и для разрешённых кодов классов
local datetime = item.datetime
local classCode = item.class_code
if Misc.yyyymmdd(datetime) == yyyymmddTradeDate and classCodes[classCode] then
local secCode = item.sec_code
if secCodesTable == nil or secCodesTable[secCode] then
local lotSize = lotSizes[secCode]
if lotSize == nil then
lotSize = (classCode == "SPBFUT") and 1 or getSecurityInfo(classCode, secCode).lot_size
lotSizes[secCode] = lotSize
end
local dirtyMinutes = newSecCodeMinutes[secCode]
if dirtyMinutes == nil then
dirtyMinutes = { count = 0, classCode = classCode }
newSecCodeMinutes[secCode] = dirtyMinutes
end
local count = dirtyMinutes.count
if count == 0 then
dirtyMinutes[1] = newCandle(item, lotSize)
dirtyMinutes.count = 1
else
local candle = dirtyMinutes[count]
if isSamePeriod(candle.hour, candle.min, datetime.hour, datetime.min, 1) then
updateCandle(candle, item.price, item.qty * lotSize)
else
count = count + 1
dirtyMinutes[count] = newCandle(item, lotSize)
dirtyMinutes.count = count
end
end
end
end
end
return newSecCodeMinutes
end
Сделал такой тест на Windows и под эмулятором Wine:
Код
function main()
message("Started at " .. os.date(), 1)
local count = 0
for i = 0, getNumberOf("all_trades") - 1 do
local item = getItem("all_trades", i)
if item then
count = count + 1
end
end
message("Ended at " .. os.date(), 1)
message("Count = " .. tostring(count))
end
Получились такие результаты: при 1.55 млн. обезличенных сделок Windows отрабатывает за 9 секунд, а Linux за 22 секунды, что приемлемо для вызова getItem(). А вот почему в 10 раз медленнее исполняется полный скрипт -- пока непонятно.
тестил версию 9.4 на демо сервере и отлаживал на ней софт для работы с потоками. ----------------- Версия понравилась. ------------------------- странно, но работает быстрее , чем 8.3. ------------------------ правда последняя - это на боевом сервере у Сбербанка. ---------------------- может сбербанк мышей не ловит? ------------------------------- кто бы их бы пнул под зад, чтобы движение у них вперед началось