Мой подход. Ядро - Движок. - страница 87
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
з.ы. Конкретно по теме хранения строк в объектах MT есть один странный глючок. Если ты начнешь сжимать данные и пользоваться непечатными символами в названии объекта, то в некоторых случаях ты не получишь доступ к этому объекту. Глюк скорее всего есть до сих пор, потому что он очень специфический и мало кто о нем знает, тем не менее ты на него можешь наткнутся.
Ясно. Только практика поможет все окончательно выяснить.
Уважаемые оппоненты.
Вот код скрипта, который:
Результат:
Петр, ну совсем ты не то и не там тестируешь. То, что ты тестируешь, должно иметь примерно одинаковую скорость по логике работы со строками.
Ты совсем не понял мой посыл.
Мой посыл был в том, что нужно перестать использовать стринги для передачи double, long,time, int и т.д. А если нужно передать текст, то переводить текстовую строку в массив uchar. И все смешанные данные различных типов через объединенные структуры данных или массивы этих структур, преобразованные в массивы uint с помощью union передавать через ресурсы, а на приеме эти массивы uint обратно преобразовывать также через union в исходные структуры. Поверь мне Петр, стринги - это очень медленно, от них нужно всегда уходить, там где это возможно. Стринги нужны только для текста и вывода на печать.
И в своем примере ты совершенно неправильно подошел к понятию замера производительности.
Тем более через свойство OBJPROP_TEXT ты сможешь передать строку с максимальным размером 63 байта. Это ни о чем.
Хоть твой пример совсем лишен всякого смысла, но я переделал его под что-то более корректное чисто для демонстрации, и вот что получилось при копировании 1000 различных строк размером 63 байта:
Код скрипта прилагаю. Он работает и на MT4 и на MT5
MT4:
МТ5:
Похоже, что в MT5 работа с объектами асинхронная, поэтому твой метод в 100 раз работает медленее и для MT5 ну совсем не годиться. А ставку сейчас нужно все больше и больше делать именно на MT5
и что это такое?:
справку то хоть читай
Уважаемые оппоненты.
Вот код скрипта, который:
Результат:
Читаем внимательно и делаем выводы: https://docs.mql4.com/ru/basis/types/stringconst
не согласен. Нам uchar массив для строки нужен как промежуточный. И конвертации никакой нет, а происходит простое копирование байтов.
не согласен. Нам uchar массив для строки нужен как промежуточный. И конвертации никакой нет, а происходит простое копирование байтов.
Пробуйте кириллицу передавать. И сравните коды символов в uchar массиве и в строке, строка идёт как массив ushort.
Я знаю, что такое юникод. Но в нашем случае нам массив uchar нужен лишь для того чтобы через union получить массив uint для дальнейшей передачи его через ресурс и при получении обратной цепочки восстановления строки. Потерь не будет. А данной задаче нам не нужно вытаскивать символы из массива uchar.
тем более внимательно изучите последний параметр у этих функций. Кодировку можно менять и по умолчанию стоит не юникод.
Петр, ну совсем ты не то и не там тестируешь. То, что ты тестируешь, должно иметь примерно одинаковую скорость по логике работы со строками.
Николай, со всем уважением, это пустые слова ниочем. Я замерил и приложил скрипт. "Правильно-неправильно подошел...", "должно иметь примерно одинаковую скорость по логике работы со строками"... Просто слова.
Nikolai Semko:
...
Ты совсем не понял мой посыл.
Мой посыл был в том, что нужно перестать использовать стринги для передачи double, long,time, int и т.д. А если нужно передать текст, то переводить текстовую строку в массив uchar. И все смешанные данные различных типов через объединенные структуры данных или массивы этих структур, преобразованные в массивы uint с помощью union передавать через ресурсы, а на приеме эти массивы uint обратно преобразовывать также через union в исходные структуры. Поверь мне Петр, стринги - это очень медленно, от них нужно всегда уходить, там где это возможно. Стринги нужны только для текста и вывода на печать.
Именно этот твой посыл я прекрасно понял. И ОН НЕПРАВИЛЬНЫЙ.
Почему? - Потому что придется в РАЗЫ усложнить систему работы с параметрами элементов управления. Архитектура хранения, передачи и управления парамерами станет В РАЗЫ более сложной и запутанной, что приведет к массе проблем и общему замедлению работы.
Ты же не понимаешь внутренней архитектуры. Ты не знаешь, как программы взаимодействуют, управляют значениями параметров в соответствии с их типом и свойствами. То, что ты предлагаешь, сделает все многократно сложнее и запутаннее. И не решит проблему связи. Она все равно останется костыльной.
...
Тем более через свойство OBJPROP_TEXT ты сможешь передать строку с максимальным размером 63 байта. Это ни о чем.
Хоть твой пример совсем лишен всякого смысла, но я переделал его под что-то более корректное чисто для демонстрации, и вот что получилось при копировании 1000 различных строк размером 63 байта:
...
Через описание одного МТ-объекта можно передать строку в 64 символа. Этого достаточно. Мне нужно - 20-30 строк для передачи данных больших таблиц. Без больших таблиц, нужно 2-3 строки максимум.
Меня сейчас интересует именно МТ4.
МТ5 все время развивается. Разрботчики могут просто добавить общую память МТ-программ (чтобы не нужно было возиться с ресурсами) и вопрос будет снят.
Nikolai Semko:
...
Мой посыл был в том, что нужно перестать использовать стринги для передачи double, long,time, int и т.д.
...
А как пересылать double, long,time, int и т.д. ???
Все равно в строку нужно переводить, а потом в char, чтобы записать в ресурс.
Или ты предлагаешь через lparam,dparam ?
То есть перегружать очередь событий...
И еще в своих замерах, ты забыл прибавить время на сохранение и чтение ресурса...
Так что, даже при записи 1000 строк (которые действительно лучше передавать через ресурс), ты не выигрываешь в скорости, из за затрат на сохранение и извлечение из ресурса.