Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
К разговору об интуиции. Хочу привести интересный пример. Мой пост, напечатанный в этой теме https://www.mql5.com/ru/forum/95632/page12 более двух лет назад:
1. Концепция графического движка.
2. Концепция графического ядра.
3. Этапы создания визуальной студии для платформы МТ.
4. Описание механизма создания интерфейса советника.
1. Графический движок представляет из себя программу выполненную в качестве индикатора. Данная программа создана исключительно для управления пользовательским интерфейсом. Выполняет набор базовых функций:
Графический движок добавляется на график также, как и любой другой индикатор. Он включает в себя следующий набор окон:
На этом, в принципе, понятие графического движка исчерпывается. Важно, что без него работа интерфейса невозможна.
2. Графическое ядро это блок информации, содержащий в себе данные всех объектов и окон интерфейса, записываемый в массиве и сохраняемый в файле.
Этот блок является цифровым отражением графического интерфейса. Загружается графическим движком по указанию пользователя. Сам графический движок имеет свое собственное, внутреннее граф. ядро которое обеспечивает работу его собственных окон, и внутри этого ядра отведено свободное место для интеграции в него пользовательского интерфейса (в цифровом виде). Интеграция осуществляется в процессе загрузки графического ядра из файла.
3. Создание визуальной студии на платформе МТ, в моем понимании делится на два этапа:
4. Я хочу изложить механизм процесса создания интефейса в общих чертах и немного приоткрыть завесу над его технологией. Пояснить, откуда появится легкость создания интерфейса через файл.
Дело в следующем: в движке имеется спец. функция, которая создает полноценное графическое ядро на основе одного файла, с минимальным количеством загрузочной информации. Загрузочная информация в этом файле имеет самопонятный и читабельный для человека вид. Ее легко писать и редактировать. Например, для создания окна досточно написать "_CREATE_NEW_WINDOW", а для создания чекбокса "_CHECKBOX" и имя этого чекбокса, (движок автоматически распознает имя элемента, как наименование самого элемента и как наименование его параметра).
Данная функция называется "G_CORE_BUILDER()" и она строит графическое ядро принимая данные из двух основных источников: из загрузочного файла создаваемого пользователем, и из массива "CONTENT[]", в котором записаны все стандартные группы объектов входящие в состав платформ окон и элементов управления. "CONTENT[]" содержит также состояния и сценарии объектов. Все в одном массиве. В общем, исходный материал из "CONTENT[]" + загрузочный файл создаваемый пользвателем используются функцией "G_CORE_BUILDER()" для построения графического ядра, с которым работает движок.
Удивительно, насколько НЕИЗМЕНИЛИСЬ термины и концепции за ДВА ГОДА упорного труда. И функции и массивы и ключ.слова, - в как здесь сказано. Все реализовано по этому сценарию. И эта технология работает и развивается. При том, что два года назад, опыта разработки языка разметки у меня НЕ БЫЛО СОВСЕМ.
Я не уперся в тупик, не изменил концепции, не поменял направление. Продолжал создавать движок, ядро и язык разметки именно так, как изначально задумал. И практика подтверждает правильность выбора пути.
Если это не пророческая интуиция, то что тогда?
Уважаемые оппоненты.
Вот код скрипта, который:
Результат:
Мое решение более чем в 10 раз быстрее.
Прибавьте к вашему решению, время на сохранение ресурса и время на получение ресурса в массив с помощью ResourceReadImage();
В моем варианте решения, ни первое, ни второе НЕ ТРЕБУЕТСЯ.
Мое решение более чем в 10 раз быстрее.
Петр, если ты работаешь со строкой то ты просядешь по производительности в любом случае. Поэтому удивительно слышать от тебя как ты гоняешься за мифической производительностью, хотя изначально выбрал негодное решение для этого: передача сообщений через строку с последующим парсингом этого сообщения.
Петр, если ты работаешь со строкой то ты просядешь по производительности в любом случае. Поэтому удивительно слышать от тебя как ты гоняешься за мифической производительностью, хотя изначально выбрал негодное решение для этого: передача сообщений через строку с последующим парсингом этого сообщения.
Василий, а как еще передавать данные всех типов между программами?
OnChartEvent() подходит частично.
И кстати, замеры меньше 20 милисекунд, строго говоря вообще не валидны, по крайней мере в системах с вытесняющей многопоточносью. Но даже если принять твой результат (в целом я это признаю), все равно это ни о чем не говорит, потому что важны издержки с учетом полного круга. А то, что ты померил, это лишь часть этого.
Нужен универсальный и самый быстрый способ. Чтобы и в тестере работал и в обход очереди событий OnChartEvent();
Как показала проверка, передача через ресурсы в 10 раз медленнее. (без замера времени на сохранение ресурса и получения из него данных с помощью ResourceReadImage()) .
Мое решение - лучший вариант при исходных условиях.
...Но даже если принять твой результат (в целом я это признаю), все равно это ни о чем не говорит, потому что важны издержки с учетом полного круга. А то, что ты померил, это лишь часть этого.
Верно, но если экстраполировать на большее количество строк и передач, мой вариант все равно выигрывает.
Василий, а как еще передавать данные всех типов между программами?
Прямой мапинг структур через union на байтовый массив, расшаренный для глобального доступа. Не знаю, реализуемо ли это технически, но если да, то скорость будет космической, т.к. копировать вообще ничего не придется.