Медленный вывод в таблицы QLua через SetCell

Страницы: 1
RSS
Медленный вывод в таблицы QLua через SetCell
 
При использовании приведённых ниже демонстрационных скриптов наблюдается повышенная нагрузка на CPU и медленный вывод содержимого в таблицы QLua. При этом вывод в заголовки окон этих таблиц производится нормально. Просьба проверить оптимальность реализации отрисовки содержимого таблиц. Используется светлая тема терминала 9.3.3.3, на тёмной не проверялось, наверное, ещё хуже будет.

В течение 7 дней можно скачать нужные демо-файлы по ссылке: https://dropmefiles.com/cNAAw  Описание приводится ниже.

Файлы RunDemo1.lua, ...m RunDemo9.lua каждый имеет свои настройки и запускают общий файл Demo.lua. Каждый скрипт выводит окно и периодически с некоторым таймаутом, заданным в Demo.lua, обновляет свою таблицу на экране. Скрипты надо запускать одновременно.

Просьба к разработчикам ответить на вопрос: считается ли такая скорость отрисовки нормальной или её стоит оптимизировать?

Файл Demo.lua:
Код
---
--- Настройки заданы в переменной config, которая к моменту запуска уже определена.
---

local interrupted = false
local tableId
local timeout = 20 -- можно уменьшать, чтобы проблема стала более явной
local nRow = 30 -- количество строк в таблице, можно увеличивать, чтобы проблема стала более явной
local nCol = 10 -- количество столбцов в таблице, можно увеличивать, чтобы проблема стала более явной

function OnInit(scriptPath)
    tableId = AllocTable()
    for colId = 1, nCol do
        AddColumn(tableId, colId, "#" .. colId, true, QTABLE_STRING_TYPE, 20)
    end
end

function OnStop()
    interrupted = true
    local tId = tableId
    tableId = nil
    if tId then
        DestroyTable(tId)
    end
end

function updateTable()
    if tableId == nil then
        return
    end
    if IsWindowClosed(tableId) then
        CreateWindow(tableId)
        SetWindowPos(tableId, config.x, config.y, config.dx, config.dy)
        for rowId = 1, nRow do
            InsertRow(tableId, rowId)
        end
    end
    local dt = os.date(" %Y-%m-%d %X", os.time())
    SetWindowCaption(tableId, config.name .. dt)
    for rowId = 1, nRow do
        for colId = 1, nCol do
            SetCell(tableId, rowId, colId, dt)
        end
    end
end

function main()
    while not interrupted do
        updateTable()
        sleep(timeout)
    end
end



Файл RunDemo1.lua:
Код
---
--- Этот скрипт нужно запустить.
---

config = {
    name = "RunDemo1",
    x = 0,
    y = 0,
    dx = 1400,
    dy = 100,
}
dofile(getScriptPath() .. "/Demo.lua")

Файл RunDemo2.lua:
Код
---
--- Этот скрипт нужно запустить.
---

config = {
    name = "RunDemo2",
    x = 0,
    y = 100,
    dx = 1400,
    dy = 100,
}
dofile(getScriptPath() .. "/Demo.lua")

Содержимое файлов 3-9 аналогично, отличаются только y-координаты окна.
 
_sk_, О, Господи! Только я уже раз 20 советовал в разных местах: "Не пользуйтесь вы таблицами Квика - есть же таблицы Луа"! Да и с таблицами Квика что за проблемы? В моей главной обычно 20-30 тысяч ячеек, и почти все они проходят не только SetCell, но и SetColor.

Ах, "Скрипты надо запускать одновременно". Ну вот она и причина всех тормозов! А у меня "local nRow обычно порядка 1000 (и может сильно меняться, если установлены какие-то фильтры), а вот "local nCol" как раз порядка 30.

И ещё один тормоз навскидку: что, при каждом выводе таблицы она набивается InsertRow? К меня так только после изменения количества строк в ней, что происходит довольно редко (при внесении нового тикера в портфель, удалении из него или при установке/снятии каких-то фильтров).
 
Цитата
Владимир написал:
_sk_, О, Господи! Только я уже раз 20 советовал в разных местах: "Не пользуйтесь вы таблицами Квика - есть же таблицы Луа"! Да и с таблицами Квика что за проблемы? В моей главной обычно 20-30 тысяч ячеек, и почти все они проходят не только SetCell, но и SetColor.

Ах, "Скрипты надо запускать одновременно". Ну вот она и причина всех тормозов! А у меня "local nRow обычно порядка 1000 (и может сильно меняться, если установлены какие-то фильтры), а вот "local nCol" как раз порядка 30.

И ещё один тормоз навскидку: что, при каждом выводе таблицы она набивается InsertRow? К меня так только после изменения количества строк в ней, что происходит довольно редко (при внесении нового тикера в портфель, удалении из него или при установке/снятии каких-то фильтров).
можете показать время исполнения скрипта при текущих торгах  ?
Спасибо
 
nikolz, А что за зверь "время исполнения скрипта при текущих торгах"? Как с утра запущены у двух брокеров, так всё это время и работают. :smile:  
 
Я видел, что как минимум 2 представителя "Арки" читали эту тему. Хотелось бы увидеть ответ на заданный вопрос.
 
_sk_, Добрый день,

Прежде всего приносим извинения за задержку с ответом.

Касательно нагрузки на CPU. Воспроизвели запуск скриптов как Вы описали, однако с  повышенной нагрузкой на CPU не столкнулись. Как и было описано Вами,  запускали все скрипты одновременно, но получили увеличение загрузки CPU  лишь на 10% (См. соответствующие скриншоты). Если есть какие-либо  дополнительная информация, просьба её предоставить.

Касательно  медленной отрисовки содержимого Lua-таблиц. Ваше письмо получено,  проблема изучается. Постараемся в ближайшее время дать ответ.
 
Спасибо за ответ.

Раз вы смогли увидеть медленную отрисовку Lua-таблиц, это уже очень хорошо, т.к. обозначенную в посте проблему можно реально воспроизвести и постараться устранить.

Когда я писал про повышенную нагрузку на CPU, то имел в виду, что процесс терминала QUIK загружает ПО МАКСИМУМУ одно ядро процессора, хотя современное железо должно справляться с такой интенсивностью вывода на экран с меньшей нагрузкой. Я не знаю, сколько ядер в машине, на которой сделаны прилагаемые скриншоты, но 11.2% уже близко к границе для 8-ядерного компьютера (100% / 8 ядер = 12.5%).

Предлагаю считать, что если разобраться с медленной отрисовкой, то и проблема, которую я обозначил как повышенная нагрузка на CPU, будет решена.
 
Загрузка в 12% - это не значит, что одно ядро все занимает. Чтобы однозначно сказать, необходимо открыть монитор ресурсов и посмотреть подробную картину для каждого ядра.
 
Цитата
Daniil Pozdnyakov написал:
получили увеличение загрузки CPU  лишь на 10%
Вообще-то на 522%. Или в пять раз. Была загрузка 0.018, стала 0.112, считаем 100 * (0.112 - 0.018) / 0.018 = 522.
 
Anton, Тогда уж в 100 * 0.112 / 0.018=622, т.е. в 6 раз. :smile:  
 
Цитата
Владимир написал:
в 6 раз
Да, верно, в 6 раз. Но на 522%, первые 100% уже были на 0.018.
 
Выскажу гипотезу, почему так получается с низкой скоростью отрисовки, и немного порассуждаю. Возможно, что я не прав.

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

Можно как-то снижать затраты на синхронизацию. Например, если бы была удобная возможность дать из потока main задачу для исполнения в потоке коллбэков, можно было бы реализовать отрисовку таблицы большим блоком, который выполнился бы быстрее, чем куча мелких задач. Что-то типа executeAsCallback на этом форуме уже обсуждали (https://forum.quik.ru/messages/forum10/message50396/topic5983/#message50396)

Но если просто починят SetCell, чтобы эта и, возможно, аналогичные функции стали существенно быстрее, тоже будет хорошо.
 
_sk_, Для меня несомненно, что:
1. Запуск сразу несколько скриптов - это ЖУТКИЕ тормоза!
2. Прорисовка таблиц - относительно дешёвая операция (особенно, если её выполнять не чаще, чем раз в секунду).
3. Никакими коллбеками, кроме OnStop и OnTrade не пользуюсь и, соответственно, ни малейших претензий к
SetCell и/или SetColor не имею.
 
_sk_, Здравствуйте.

Мы провели анализ предоставленных скриптов. Параметр timeout  устанавливают интервал перезаполнения каждой таблицы в 20 мс. Отметим,  что для таблиц qlua существует интервал перерисовки таблиц, равный 50 мс  (для снижения процессорной нагрузки). В данном случае таблицы просто не  успевают перерисовываться, так как в них постоянно поступают  обновленные данные. Интервал перезаполнения в 20 мс кажется нам явно  избыточным, рекомендуем его увеличить хотя бы до 100 мс.

Так же мы готовы разбираться с данной задачей, если вы можете  предоставить нам скрипты, в которых такая частота обновления таблицы  имеет практический смысл.
 
Ясно. Спасибо за попытку.
Страницы: 1
Читают тему
Наверх