SearchItems - потокобезопасная итерация

Страницы: 1
RSS
SearchItems - потокобезопасная итерация
 
Я пользуюсь нижеприведенным вариантом для получения подвыборки строк из таблицы, в данном примере из таблицы orders.
Код
function find_active_orders(class_code, sec_code)

    function matchItem(_flags, _class_code, _sec_code)
      return bit.band(_flags, 0x1) ~= 0
        and _class_code == class_code
        and _sec_code == sec_code
    end

    local indexes = SearchItems("orders", 0, getNumberOf("orders")-1, matchItem, "flags,class_code,sec_code")
    if indexes == nil then return {} end
    local res = {}
    for i=1, #indexes do
      local item = getItem("orders", indexes[i])
      if matchItem(item.flags, item.class_code, item.sec_code) then
        res[#res+1] = item
      end
    end
    return res
end

В строке if matchItem(item.flags, item.class_code, item.sec_code) then я дополнительно проверяю, что полученная заявка соответствует изначальному фильтру на случай, если таблица orders будет изменена и в нее будут добавлены новые заявки в произвольном порядке.

Два вопроса:

1) Необходима ли повторная проверка или можно полагаться, что а) строки не удаляются,  б) новые заявки помещаются в конец таблицы и в) порядок строк не меняется в течение торгового дня? Если так, применима ли такая модель ко всем таблицам в Quik (строки никогда не удаляются, новые добавляются в конец, порядок строк зафиксирован).

2) По ходу биржевого дня количество строк в таблице постоянно увеличивается и доходит до 20000, в результате постоянного изменения лимитных заявок по цене (снять старую, выставить новую по другой цене). При этом активных заявок только несколько сотен. При каком размере таблицы имеет смысл задуматься о производительности функции find_active_orders и как ее можно было ускорить для случая когда практически все заявки неактивные?
 
Здравствуйте.
Цитата
1) Необходима ли повторная проверка или можно полагаться, что а) строки  не удаляются,  б) новые заявки помещаются в конец таблицы и в) порядок  строк не меняется в течение торгового дня? Если так, применима ли такая  модель ко всем таблицам в Quik (строки никогда не удаляются, новые  добавляются в конец, порядок строк зафиксирован).
Произвольно строки из таблицы заявок не удаляются, не перемешиваются между собой в произвольном порядке и так далее. Поэтому, проверку можно не применять.
Касательно применения модели ко всем таблицам - тут нужно уточнить о каких таблицах идет речь и какая задача стоит. Большинство таблиц в терминале настраиваются пользователем, но правило построения (строки не перемешиваются, не удаляются и так далее) ко всем одинаковое.
Цитата
2) По ходу биржевого дня количество строк в таблице постоянно  увеличивается и доходит до 20000, в результате постоянного изменения  лимитных заявок по цене (снять старую, выставить новую по другой цене).  При этом активных заявок только несколько сотен. При каком размере  таблицы имеет смысл задуматься о производительности функции  find_active_orders и как ее можно было ускорить для случая когда  практически все заявки неактивные?
Уточните, пожалуйста, снятие лимитной заявки и выставление новой так же происходит с помощью робота или же вручную? Большая часть строк заявок из таблицы можно убрать через редактор настроек таблицы (убрать галочку "Снятые").
QUIK clients support
 
  • На данный момент я использую только таблицы orders и depo_limits.
  • Большое кол-во строк только в таблице orders.
  • Замена заявки производится программно путем отправки транзакции KILL с последующим NEW_ORDER
Поиск активных заявок в таблице размером 26000 (практически все неактивные) занимает около 75 мс, хотелось бы сократить.
 
Попробуйте выполнять поиск активных заявок в таблице, в которой отфильтрованы данные по снятым заявкам.
Как уже ранее оговаривалось, отфильтровать таблицу необходимо убрав галку "Снятые" в настройках таблицы.
После сообщите о результате, пожалуйста.
QUIK clients support
 
Разницы во времени выполнения работу функции не наблюдаю. Попробовал следующие:

1) Отключить фильтр Отмененные
2) Убрать цветовую кодировку
3) Минимизировать кол-во колонок
4) Убрать таблицу из интерфейса


Измеряю в виде расчеты дельты между датами sysdate.

Правильно я догадываюсь, что таблицы в интерфейсе могут как-то влиять на скорость выполнения функции SearchItems?
 
Решил задачу поддержанием в памяти начального индекса, с которого производится поиск (вместо 0). По ходу торгов индекс постоянно увеличивается и большую часть снятых заявкок искать не нужно.
Страницы: 1
Читают тему (гостей: 1)
Наверх