CopyTicksRange () в MQL5 некорректно работает.a - страница 5
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Да, описание функций я читаю до конца и если есть сомнения, то еще и по форумам пороюсь. Понятие быстро это у всех разное. Динамика по определению работает медленнее, так как идет постоянное перераспределение памяти. Второй минус фрагментация , иногда с динамикой ошибешься и потом памяти не хватает терминал закрыть :)))
Пинг тут не при чем, после первой закачки тики отдаются уже из базы, в теории конечно :) Меня так учили - программу надо ускорять оптимизацией, а не аппаратной базой - это уже на автомате. Да и какая разница, какой коннект - сегодня один, завтра другой - это ж от алгоритма не зависит.
Кроме БКС у меня еще Открытие, Альпари и т.д. везде есть нюансы. У меня задача сейчас обкатка математики на тиках, а не торговля или фриланс.
Еще раз, для слабовидящих:
Из справки
Функция CopyTicksRange() предназначена для запроса тиков из строго указанного диапазона, например, за конкретный день истории.Из справки
Функция CopyTicksRange() предназначена для запроса тиков из строго указанного диапазона, например, за конкретный день истории.
Функция CopyTicksRange() не дает получить тики из строго указанного диапазона "2021.01.29 23:57:00:000, 2021.01.31 23:59:00:000". Возвращает тики из совсем другого диапазона.
Просьба предоставить замеры по этому утверждению. Вопросам производительности в боевых советниках уделяю большую роль.
Вот пример кода. Писал второпях, могут быть ляпы. Замеры по следующим вариантам:
1) самый чернушный, когда массив расширяется по мере необходимости
2) чуть оптимизированный - когда расширяется на предполагаемую порцию
3) еще чуть оптимизированный - расширяется с запасом на несколько порций
4) статическая память, которая понятно будет всегда ноль
Понятное дело, что если динамически выделить огромный объем памяти под все на свете - то скорость будет как на статике, но это редко бывает
На динамически расширяемых массивах самое поганое это фрагментация памяти, которая всю ее сожрет в процессе работы. Ну и постоянно растущее время на очередное расширение - т.к. в сильно фрагментированной памяти дольше искать подходящий кусок
результаты в микросекундах. Резкое возрастание потребного времени в первой колонке ближе к концу связано скорее всего с тем, что терминал вероятно выделяет память под массивы небольшими блоками, оптимизирует немного за нас. Но когда массив становится больше блока, начинает тупо искать первый подходящий пустой кусок. Я покрутил гораздо дальше, там очень долго становится... по нескольку секунд. А было всего лишь около 1000000 ячеек
Вот пример кода. Писал второпях, могут быть ляпы. Замеры по следующим вариантам:
1) самый чернушный, когда массив расширяется по мере необходимости
2) чуть оптимизированный - когда расширяется на предполагаемую порцию
3) еще чуть оптимизированный - расширяется с запасом на несколько порций
4) статическая память, которая понятно будет всегда ноль
Понятное дело, что если динамически выделить огромный объем памяти под все на свете - то скорость будет как на статике, но это редко бывает
На динамически расширяемых массивах самое поганое это фрагментация памяти, которая всю ее сожрет в процессе работы. Ну и постоянно растущее время на очередное расширение - т.к. в сильно фрагментированной памяти дольше искать подходящий кусок
результаты в микросекундах. Резкое возрастание потребного времени в первой колонке ближе к концу связано скорее всего с тем, что терминал вероятно выделяет память под массивы небольшими блоками, оптимизирует немного за нас. Но когда массив становится больше блока, начинает тупо искать первый подходящий пустой кусок. Я покрутил гораздо дальше, там очень долго становится... по нескольку секунд. А было всего лишь около 1000000 ячеек
А у меня так получается
Правда подправил немного
А если инициализировать массивы
то так
это проверено уже два года!
Вот упертый! Почитай, что написали выше - CopyTicks точно также глючит. Если тебе нравится искать способы заставить кривую функцию работать или искать кривые способы обхода, так не мешай - тут не об этом
За два-то года можно было понять, что если функция работает не так как вам хотелось-бы и разработчики зная об этом не исправляют, то это не называется багом…
Пальцы в растопырку, крутые образованные программисты………
INT_MAX = 2147483647
вы фактически сразу отхапали INT_MAX* sizeof(double) кусок памяти и дальше работаете как со статикой
можно тогда было написать:
double d[ INT_MAX]; - будет для вас тоже самое, что и
отличие будет только в работе функции ArraySize(), а памяти отхапается сразу на всю катушку
Исправили, будет сегодня в бете.
вот спасибо большое. Пойду накачу на радостях :) обходной вариант уж очень ресурсоемкий был
Исправили, будет сегодня в бете.