Особенности языка mql5, тонкости и приёмы работы - страница 262
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В реальности TimeToStruct редко используется
В целом я согласен, но буквально на днях была задача, в которой TimeToStruct использовался около 1000 раз в секунду. Мелочь, конечно, но приятная мелочь.
Напомню, что затянувшееся обсуждение родилось из предложенного метода создания оптимальных мини-алгоритмов.
Например, в этом коде выделены строки, которые были получены через этот механизм.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Особенности языка mql5, тонкости и приёмы работы
fxsaber, 2024.05.06 23:50
В целом согласен, но буквально на днях была задача, когда TimeToStruct использовалась около 1000 раз а сек. Мелочь конечно, но приятная мелочь.
Я использую кеширование, например, при вычислении HMAC SHA-256 ключа для REST-API, который вычисляется долго, а применяется несколько раз в минуту в случайные моменты.
Но функцию, имеющую точность 1 сек, и вызываемую многажды в секунду, я бы рассчитывал раз в секунду (т.е. контроль извне). Ваше решение - тоже вариант, но делать внутреннее кеширование в каждом подобном случае похоже на костыли.
1000 раз в секунду? Я не могу представить, как это возможно?
Ну может я слегка преувеличил насчет 1000, но несколько сотен раз в секунду это точно. Для 4K экранов может и 1000.
Шкала времени для динамического чарта в пиковую нагрузку
думаю, все же существуют задачи и вне GUI. Но пока, соглашусь, сложно это представить.
Я использую кеширование, например, при вычислении HMAC SHA-256 ключа для REST-API, который вычисляется долго, а применяется несколько раз в минуту в случайные моменты.
Но функцию, имеющую точность 1 сек, и вызываемую многажды в секунду, я бы рассчитывал раз в секунду (т.е. контроль извне). Ваше решение - тоже вариант, но делать внутреннее кеширование в каждом подобном случае похоже на костыли.
где здесь костыльность?
не вижу костыльности в том, чтобы не считать заново то, что уже было посчитано до этого. Пусть это и будет стоить 20 байт лишней памяти, отведенных на статический переменные
где здесь костыльность?
Я имею в виду, что реализовывать кеш придётся для каждого случая отдельно, где это применимо. Вместо того, чтобы не запускать расчёты, когда это не надо.
Не считаю, что кеш не полезная вещь. Файлы в ОС кешируются, и при частых операциях доступны очень быстро. Но в программе можно и нужно держать часто нужные данные в памяти, а не в файлах. Привёл как пример или аналогию.
Я уже сказал, что Ваш способ тоже применим. Но можно зайти с другой стороны.
Я имею в виду, что реализовывать кеш придётся для каждого случая отдельно, где это применимо. Вместо того, чтобы не запускать расчёты, когда это не надо.
Не считаю, что кеш не полезная вещь. Файлы в ОС кешируются, и при частых операциях доступны очень быстро. Но в программе можно и нужно держать часто нужные данные в памяти, а не в файлах. Привёл как пример или аналогию.
Я уже сказал, что Ваш способ тоже применим. Но можно зайти с другой стороны.
Не понял, про какую сторону идёт речь. Похоже, Вы не вникли в суть кода. В данном случае вычисления есть всегда, только часть из них, самая затратная, использует сохраненные значения в статических переменных, если входное время того же дня, что и предыдущее входное время.
Именно потому, что Вы автор идеи, будете стоять на защите до последнего. Нет причины заводиться, это Вы не поняли меня.
Я говорю не о том, что расчёт идёт в тот же день, а о том, что Вы рассчитываете сотни раз в секунду, хотя результат имеет точность 1 секунду, и достаточно вызывать функцию раз в секунду (это и есть заход с другой стороны).
Я говорю не о том, что кеш раз в сутки не полезен, а о неудачном примере вызова функции многажды в секунду.
На этом откланиваюсь. Не люблю затянувшиеся дебаты и тем более холивары.Я использую кеширование, например, при вычислении HMAC SHA-256 ключа для REST-API, который вычисляется долго, а применяется несколько раз в минуту в случайные моменты.
Но функцию, имеющую точность 1 сек, и вызываемую многажды в секунду, я бы рассчитывал раз в секунду (т.е. контроль извне). Ваше решение - тоже вариант, но делать внутреннее кеширование в каждом подобном случае похоже на костыли.
Именно потому, что Вы автор идеи, будете стоять на защите до последнего. Нет причины заводиться, это Вы не поняли меня.
Я говорю не о том, что расчёт идёт в тот же день, а о том, что Вы рассчитываете сотни раз в секунду, хотя результат имеет точность 1 секунду, и достаточно вызывать функцию раз в секунду (это и есть заход с другой стороны).
Я говорю не о том, что кеш раз в сутки не полезен, а о неудачном примере вызова функции многажды в секунду.
На этом откланиваюсь. Не люблю затянувшиеся дебаты и тем более холивары.Сложно понять о чем Вы говорите
Я не автор идеи, я лишь попытался убыстрить и расширить существующие функции. А, если речь про хеширование, то да. Это моя идея.
Я вовсе не заводился.
Такое ощущение, что Вы почему-то думаете, что на вход данной функции подается текущее время, раз говорите о точности в 1 секунду. На вход данной функции подается разное не текущее время. Для демонстрации этого и записал анимационную гифку выше, в которой наглядно видно, что с помощью этой функции формируется нижнаяя шкала дата-время. Причем видно, что частота обращения к функции TimeToStruct2100() составляет сотни раз в секунду, чтобы сформировать временные шкалы разных масштабов. В случае хеширования эта функция в среднем работает быстрее примерно в два раза.