SearchItems

[QApplication]

Добрый день.
Планируете реализовать функцию ?
TABLE SearchItems(STRING table_name, NUMBER start_index, NUMBER end_index, FUNCTION fn [, STRING params])
Разработчики quik утверждают, что скорость получения данных из таблиц быстрее чем getItem(...), но насколько точно выяснить не удается без реализации.
Это особенно актуально для таблиц alltrade (~ 50-80 тыс. значений) and securities (~ 20 тыс. значений)

[QApplication]

Добрый день.
Появляются первые кастомные исследования по быстродействию SearchItems .
Планируете ли ее реализацию и если да, то когда ожидать?

[elelel]

Пока я не планирую ее писать, для вызова FUNCTION fn нужно придумать удовлетворительную генерализацию.

По поводу быстродействия, если оно существенно, я рекомендую начать оптимизацию с общей архитектуры робота. В первую очередь, нужно учитывать что Quik - изначально был терминал для конечного пользователя, не занимающегося трансформацией данных и подобными вещами. Lua интерфейс построен сверху этих требований. Поэтому весь Lua интерфейс можно условно поделить на функции, работающие с "первичными" данными и "вторичными" данными. Вторичные данные - это те, которые построены на основе первичных. Например, информация о конкретной сделке, транслируемая с биржи - первична. Программист не может ее получить без помощи Quik. А свеча, отрисованная за период по таким сделкам - вторична, зная сделки и время, она может быть обсчитана программистом и без функций Quik по свечам. Из-за этого в Qluacpp не было изначально функций по чисто "вторичным" функциям, типа того же получения отстроеных сервером Quik свечей. Необходимость в таких функциях я вижу только если вы пишете скрипт, который должен "совпадать" по отображению данных с данными Quik, например скрипт на продажу, который должен рисовать пользователю графики ровно так же, как делает это Quik.

Функция SearchItems вторична и (почти) во всех случаях - лишняя нагрузка на производительность, если вы работаете с первичными данными. В случае с securities наиболее разумно все бумаги кешировать в структуру один раз при старте скрипта, данная структура должна быть оптимизирована по полю или полям, по которому будет поиск. Например std::map (логарифмический поиск по ключу) или std::unordered_map (константное время поиска, но нужна эффективна хеш-функция). Если у вас бумаги не меняются в течении сессии, это однозначно более оптимальный подход. Если меняются, тоже оптимальный, но потребует труда по обновления. В случае с alltrade, зависит от того, что вы делаете, но в большинстве случаев выгоднее, получать данные по трейд-коллбеку, фильтровать их и хранить в своих структурах, чем пользоваться их огромной таблицей и использовать бриджинг вызовов в Lua, чтоб с ней что-то делать.

[QApplication]

Я примерно так и делаю, только периодически пользуюсь getItem для alltrade в случае прерывания связи и записи тиковых данных в архив.
Предполагал, что можно реализовать доступ к таблице alltrade через константный указатель в отдельном потоке, чтобы не подвисалась работа QUIK и скриптов. Думаете это возможно?
И поскольку в alltrade приходят все тики, а я использую только часть инструментов, то предполагал что применение SearchItems будет требовать меньше времени работы.

[elelel]

Предполагал, что можно реализовать доступ к таблице alltrade через константный указатель в отдельном потоке, чтобы не подвисалась работа QUIK и скриптов. Думаете это возможно?

Возможно, только синхронизацию делайте через lock-free структуру, а не что-либо, что будет вызывать системные локи потоков. См. пример logalltrade.