Тестируем 'CopyTicks' - страница 23
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Оптимально скачать что нужно к себе на большую глубину один раз, а потом докачивать только новое из ближнего кеша за микросекунды.
Если каждый раз делать глубокие запросы с проваливанием к диску, то тут конечно сам виноват.
Можете показать код самого оптимального получения истории тиков за первую неделю сентября?
Пишите сами, это не сложная задача.
По точным датам сделайте запрос и сохраните в локальном массиве. Никакой оптимальности нет при работе вне кеша. Оптимизация имеет смысл только при докачке последних 4096 тиков из кеша.
Пишите сами, это не сложная задача.
По точным датам сделайте запрос и сохраните в локальном массиве.
Так нельзя заранее знать, сколько было тиков на требуемом интервале. Параметр count не определить. Вот в чем проблема.
Выкачиваться ВСЮ история с начала сентября, задав count = триллиард - можно, конечно. Затем бинарным поиском найти в массиве конечную дату и обрезать.
Но этот триллиард - это не технический подход совсем. Нужна либо перегрузка функции с from, to. Либо доступ по индексу к базе.
Оптимизация имеет смысл только при докачке последних 4096 тиков из кеша.
Из справки:
Скорость выдачи: терминал хранит по каждому символу 4096 последних тиков в кеше для быстрого доступа (для символов с запущенным стаканом – 65536 тиков)
Мы подготовим улучшения в работе CopyTicks в ближайшем билде:
Мы подготовим улучшения в работе CopyTicks в ближайшем билде:
Спасибо!
О полностью закачанной истории from & to, видимо, будет говорить нулевой GetLastError.
Обратите внимание, что сейчас (и с вводом обозначенных Вами улучшений) крайне сложно заполучить тик, который был перед временем from. Поэтому предлагаю сделать count и отрицательным - запрос тиков не только в будущее (вправо), но и в прошлое (как при from == 0).
Тогда всегда будет удобно и оптимально (Ваша реализация) делать запрос на предшествующую историю.
Спасибо!
О полностью закачанной истории from & to, видимо, будет говорить нулевой GetLastError.
Обратите внимание, что сейчас (и с вводом обозначенных Вами улучшений) крайне сложно заполучить тик, который был перед временем from. Поэтому предлагаю сделать count и отрицательным - запрос тиков не только в будущее (вправо), но и в прошлое (как при from == 0).
Тогда всегда будет удобно и оптимально (Ваша реализация) делать запрос на предшествующую историю.
Лучше сразу сделать перегрузки CopyTicks() такими же, как и у других Copy...() функций.
Тогда придется отказаться от дефолтных count и from.
Почему? На примере CopyBuffer, сейчас имеем вот это:
int indicator_handle, // handle индикатора
int buffer_num, // номер буфера индикатора
datetime start_time, // с какой даты
int count, // сколько копируем
double buffer[] // массив, куда будут скопированы данные
);
Есть count и from (start_time).
Вы предлагаете добавить это:
int indicator_handle, // handle индикатора
int buffer_num, // номер буфера индикатора
datetime start_time, // с какой даты
datetime stop_time, // по какую дату
double buffer[] // массив, куда будут скопированы данные
);
Чтобы копировать можно было в обе стороны, верно? Только, вместо datetime - ulong (в микросекундах).
Останется, на будущее, для каких-нибудь других целей добавить такую перегрузку:
int CopyBuffer(
int indicator_handle, // handle индикатора
int buffer_num, // номер буфера индикатора
int start_pos, // откуда начнем
int count, // сколько копируем
double buffer[] // массив, куда будут скопированы данные
);
И все.
Тогда придется отказаться от дефолтных count и from.
Невнимательно прочитал вначале... да, придется. Ну и что? Если разработчики расширят кэш - будет медленнее только при загрузке достаточно большой тиковой истории, а этого часто ведь не нужно делать. А на подгрузку в реальном времени никак не скажется (будет браться из кэша).
Я считаю, гораздо важнее сделать загрузку с даты по дату, чем пытаться сохранить дефолтные параметры.