alsu: Этот код отлажен, и какого-либо заметного замедления в работу индикаторов не вносит, но можете посчитать время непосредственно, если уж так это критично.
ArrayResize() - вносит, и еще как. Но это если элементов много, от сотни тысяч. Тыц.
ArrayResize() - вносит, и еще как. Но это если элементов много, от сотни тысяч. Тыц.
но только если ресайзов тоже тысячи. А если их по одному на каждый бар - в реалтайме замедление неощутимо даже при большом количестве баров. По крайней мере, это не дольше, чем расчет какого-нибудь не самого простого индикатора
Элементарно,Ватсон. Как только Вы добавляете в этот массив что-то новенькое, из него тотчас-же уходит нечто старенькое :)
Вы в любой момент работы программы можете обратиться к любому значению индикаторного буфера от 0 до Bars-1, и никуда они не уходят. Поэтому при Bars=100 и Bars=1 000 000 буфер уж точно не может иметь одного и того же размера (если, конечно не выделяется память сразу под миллион баров - но тогда где гарантия, что в процессе их не станет еще больше? все равно придется довыделять).
Вывод такой, даже если буфер обслуживать самому, мт очень долго выделяет память под большие массивы. Например 7 массивов по 250 000 элементов, выделяются где то 30 секунд. По этому проще при нехватке буферов использовать буферы с помощью iCustom.
Можно так попробовать, не пробовал, но думаю будет нормально:
Обычный массив, на запуске масштабируем по количеству баров плюс, пусть 1000. Затем вычисляем индекс элемента. Если i - индекс индикаторного буфера, то к соответсвующему элементу массива обращаться как к Bars-i-1.
Когда количество баров становится больше размера массива, увеличить его еще на 1000.
Но самое интересное то, что почти во всех случаях, когда не хватает буферов можно вообще обойтись без буферов и массивов, вместо одного буфера достаточно пары переменных. Пример здесь.
Но самое интересное то, что почти во всех случаях, когда не хватает буферов можно вообще обойтись без буферов и массивов, вместо одного буфера достаточно пары переменных. Пример здесь.
Да, как правило, можно обойтись парой переменной, одна из ктр. - для предыд. значения - статическая. Но - увы - не всегда.
Когда количество баров становится больше размера массива, увеличить его еще на 1000.
Я примерно тоже самое хоте сделать, но ресайз больших массивов >20к, дорогое по времени удовольствие + вешает терминал если используем в индикаторе. Как я писал в предыдущем посте, можно создать изначально большие массивы, и работать с ними без постоянного увеличения, но проблема в том, что по каким то причинам мт очень долго их инициализирует.
Поиск сдох, да? )))
Когда не хватает индикаторных массивов, и вот еще обсуждение нектр. специфики Число буферов в индикаторе
ArrayResize() - вносит, и еще как. Но это если элементов много, от сотни тысяч. Тыц.
ArrayResize() - вносит, и еще как. Но это если элементов много, от сотни тысяч. Тыц.
Элементарно,Ватсон. Как только Вы добавляете в этот массив что-то новенькое, из него тотчас-же уходит нечто старенькое :)
Вывод такой, даже если буфер обслуживать самому, мт очень долго выделяет память под большие массивы. Например 7 массивов по 250 000 элементов, выделяются где то 30 секунд. По этому проще при нехватке буферов использовать буферы с помощью iCustom.
Svinozavr - спасибо за ссылки.
Можно так попробовать, не пробовал, но думаю будет нормально:
Обычный массив, на запуске масштабируем по количеству баров плюс, пусть 1000. Затем вычисляем индекс элемента. Если i - индекс индикаторного буфера, то к соответсвующему элементу массива обращаться как к Bars-i-1.
Когда количество баров становится больше размера массива, увеличить его еще на 1000.
Но самое интересное то, что почти во всех случаях, когда не хватает буферов можно вообще обойтись без буферов и массивов, вместо одного буфера достаточно пары переменных. Пример здесь.
Но самое интересное то, что почти во всех случаях, когда не хватает буферов можно вообще обойтись без буферов и массивов, вместо одного буфера достаточно пары переменных. Пример здесь.
Когда количество баров становится больше размера массива, увеличить его еще на 1000.