Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Нашел - не принтовался результат выполнения функции, поэтому оптимизатор (он есть!) компилятора выкидывал то, что использоваться все равно не будет. Исправил исходник. Второй вариант все равно аутсайдер.
В общем, вывод такой, что в компиляторе оптимизатор есть, но вот с такой простой задачей не справляется.
Рекомендую проверить наличие в своих исходниках "второго варианта" (или, что еще хуже, "четвертого") и устранить его. Как быстро проверить - непонятно.
Как указали выше, все ваши затраты в необоснованных с вашей стороны копированиях структуры, которую компилятор не имеет права выкинуть.
Забудьте про const и ваше понимание языка программирования здорово улучшится. Const не влияет на оптимизацию в C++ языке. Это массовое заблуждение.
Const модификаторы в C/С++ подобных языках сделаны для контроля случайных модификаций программистами + по мелочи.
Использую ради самоконтроля. Сильно выручало иногда. Даже на начальном этапе архитектуры const-модификаторы могут подсказать, что не до конца продумано что-то.
В оптимизации кода практически нулевое влияние. Тем более на современных C++ компиляторах, которые и без программиста прилично вычисляют изменяемость переменных.
Спасибо, буду знать. Надеюсь, подтянется и MQL5.
Как указали выше, все ваши затраты в необоснованных с вашей стороны копированиях структуры, которую компилятор не имеет права выкинуть.
Компилятор иногда много всего выкидывает. Почему здесь не может сделать оптимально, так и не понял.
Писать самый быстрый первый вариант не хочется, т.к. бывает, что совсем нечитабельно. Третий - сильное нагромождение лишних сущностей (обход отсутствия указателей).
И странно, что третий медленнее первого.
Использую ради самоконтроля. Сильно выручало иногда. Даже на начальном этапе архитектуры const-модификаторы могут подсказать, что не до конца продумано что-то.
Спасибо, буду знать. Надеюсь, подтянется и MQL5.
В MQL5 это вовсю используется.
Вы зря думаете, что у нас недостаточная оптимизация.
Компилятор иногда много всего выкидывает. Почему здесь не может сделать оптимально, так и не понял.
Писать самый быстрый первый вариант не хочется, т.к. бывает, что совсем нечитабельно. Третий - сильное нагромождение лишних сущностей (обход отсутствия указателей).
И странно, что третий медленнее первого.
Потому, что это неведомый объект с неизвестным поведением в отличие от простых типов.
Это простой тип типа int можно как угодно вертеть и оптимизировать. А объект/структуру он обязан скопировать.
Для информации: string - это тоже сложный объект.
Потому, что это неведомый объект с неизвестным поведением в отличие от простых типов.
Это простой тип типа int можно как угодно вертеть и оптимизировать. А объект/структуру он обязан скопировать.
Для информации: string - это тоже сложный объект.
Ренат, интересует вопрос как раз по string, индикатор шпион можно передать по int и string-название символа,
если через int, сейчас передаю номер символа через int, а внутри функции уже из структуры берется название символа,
вопрос может запутан, если сразу можете дать рекомендацию
---
add
т.е. сразу передать в функцию название символа, или через int и внутри функции получить из структуры
вопрос крайне актуальный, т.к. сразу идет поток по всем тикам и обычно гораздо больше одного символа
Потому, что это неведомый объект с неизвестным поведением в отличие от простых типов.
Разве штатные сложные типы (MqlTradeRequest, string) неизвестны? Если в кастомной структуре нет операторов и конструктора с деструктором, то что там может мешать?
Вроде, c PSO-структурами все отлично. Например, MqlTick.
Из Документации:
Подход такой же, как четвертый вариант. Только тип простой используется. В примере выше из документации на каждой итерации выделяются четыре байта с записью туда соответствующего значения?
Разве штатные сложные типы (MqlTradeRequest, string) неизвестны? Если в кастомной структуре нет операторов и конструктора с деструктором, то что-там может мешать?
Вроде, c PSO-структурами все отлично. Например, MqlTick.
Из Документации:
Подход такой же, как четвертый вариант. Только тип простой используется. В примере выше из документации на каждой итерации выделяются четыре байта с записью туда соответствующего значения?
Вы невнимательно читаете мои объяснения.
Компиляторы еще не научились(да это и бред) анализировать графы использования каждого поля в любом инстансе объекта, чтобы оптимизировать "копирование только нужного", "переупаковке(а этого вы тоже захотите)" и "вызову только нужного" у конкретного инстанса объекта.
По простой причине - это породит комбинаторный взрыв в миллионы раз бОльшие расходы. Компиляторы С++ даже сейчас задыхаются и самоограничиваются на глобальной оптимизации результирующего файла.
Поэтому остается одна схема "объект не меняет формы и методов", его конструируют/копируют полноценно(если разработчик не реализовал экономные методы конструкторов/копирования) и оптимизация в этом месте конструирования/копирования сильно ограничена.
Грубо - все, что сложнее скалярного числа, является сложным объектом.
Любые встроенные структуры вне зависимости от их PODнутости - сложные и неизвестные объекты, не имеющие преимуществ. Разве что скопировать POD одной командой memcpy можно. Объяснение выше.
Datetime - это простой uint64, который отлично оптимизируется.Спасибо за подробности. Тогда точно надо искать слабые места. Просьба все же ускорить историю.