MetaQuotes:
Первый вызов функции из внешней библиотеки требует загрузки и инициализации этой
библиотеки практически как вызов из DLL. Это занимает существенное
время. Последующие вызовы уже будут работать быстро. Попробуйте
провести замеры, отбросив первый вызов.
В любом случае, вызов из библиотек будет медленнее MQL4 кода, подключенного
через #include.
Внимательно прочитал пояснения ,но не понял одного - как получается
более быстрый вызов через #include , если этот файл по структуре
внутри также вызывает библиотеку.
#include "имя_файла.mq4/mqh" включает исходный код в сборку скрипта, вызываемые функции
работают в одном адресном пространстве виртуальной машины
MQL4. Это статическоевключение на этапе компиляции.
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
#import "имя_файла.ex4" импортирует функции из внешнего модуля, который запускается
в отдельном адресном пространстве виртуальной машины MQL4. Это
динамическое связывание на этапе выполнения.
В этом случае большой оверхед на первом вызове, так как происходит
создание отдельной копии виртуальной машины, наследование
окружения от родительского скрипта, подгрузка библиотеки EX4,
ее инициализация и связывание функций. Последующие вызовы импортированных
функций работают быстро, но все равно медленнее, чем простой
"call XXXX". Импорт функций из DLL библиотек работает чуть проще
и быстрее, чем импорт из EX4.
#include "имя_файла.mq4/mqh" включает исходный код в сборку скрипта, вызываемые функции
работают в одном адресном пространстве виртуальной машины
MQL4. Это статическоевключение на этапе компиляции.
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
#import "имя_файла.ex4" импортирует функции из внешнего модуля, который запускается
в отдельном адресном пространстве виртуальной машины MQL4. Это
динамическое связывание на этапе выполнения.
В этом случае большой оверхед на первом вызове, так как происходит
создание отдельной копии виртуальной машины, наследование
окружения от родительского скрипта, подгрузка библиотеки EX4,
ее инициализация и связывание функций. Последующие вызовы импортированных
функций работают быстро, но все равно медленнее, чем простой
"call XXXX". Импорт функций из DLL библиотек работает чуть проще
и быстрее, чем импорт из EX4.
Если я Вас правильно понял - при компиляции внутри #include прописывается
конкретный путь к вызываемой через него библиотеке и за счет
этого повышается скорость обращения?
#include "имя_файла.mq4/mqh" включает исходный код в сборку скрипта, вызываемые функции
работают в одном адресном пространстве виртуальной машины
MQL4. Это статическоевключение на этапе компиляции.
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
#import "имя_файла.ex4" импортирует функции из внешнего модуля, который запускается
в отдельном адресном пространстве виртуальной машины MQL4. Это
динамическое связывание на этапе выполнения.
В этом случае большой оверхед на первом вызове, так как происходит
создание отдельной копии виртуальной машины, наследование
окружения от родительского скрипта, подгрузка библиотеки EX4,
ее инициализация и связывание функций. Последующие вызовы импортированных
функций работают быстро, но все равно медленнее, чем простой
"call XXXX". Импорт функций из DLL библиотек работает чуть проще
и быстрее, чем импорт из EX4.
Если я Вас правильно понял - при компиляции внутри #include прописывается
конкретный путь к вызываемой через него библиотеке и за счет
этого повышается скорость обращения?
Нет, включается код в программу как будто бы вы его там написали.
Исходный код. И при компиляции получается полностью самодостаточная
программа, за одним исключением - исполняться может только в
среде терминала.
А когда делаем #import этого не происходит и библиотеку надо тоже
предоставлять.
Мне больше нравится #include. Больше гибкости и меньше думать. Если
конечно DLL не использовать, там без этого не обойтись.
#include "имя_файла.mq4/mqh" включает исходный код в сборку скрипта, вызываемые функции
работают в одном адресном пространстве виртуальной машины
MQL4. Это статическоевключение на этапе компиляции.
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
#import "имя_файла.ex4" импортирует функции из внешнего модуля, который запускается
в отдельном адресном пространстве виртуальной машины MQL4. Это
динамическое связывание на этапе выполнения.
В этом случае большой оверхед на первом вызове, так как происходит
создание отдельной копии виртуальной машины, наследование
окружения от родительского скрипта, подгрузка библиотеки EX4,
ее инициализация и связывание функций. Последующие вызовы импортированных
функций работают быстро, но все равно медленнее, чем простой
"call XXXX". Импорт функций из DLL библиотек работает чуть проще
и быстрее, чем импорт из EX4.
Если я Вас правильно понял - при компиляции внутри #include прописывается
конкретный путь к вызываемой через него библиотеке и за счет
этого повышается скорость обращения?
Нет, включается код в программу как будто бы вы его там написали.
Исходный код. И при компиляции получается полностью самодостаточная
программа, за одним исключением - исполняться может только в
среде терминала.
А когда делаем #import этого не происходит и библиотеку надо тоже
предоставлять.
Мне больше нравится #include. Больше гибкости и меньше думать. Если
конечно DLL не использовать, там без этого не обойтись.
А почему компилятор ругается , что не опознает код, если в #include
вставляшь исполняемый скрипт? Хотя затем советник работает
с этим файлом корректно.
#include "имя_файла.mq4/mqh" включает исходный код в сборку скрипта, вызываемые функции
работают в одном адресном пространстве виртуальной машины
MQL4. Это статическоевключение на этапе компиляции.
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
#import "имя_файла.ex4" импортирует функции из внешнего модуля, который запускается
в отдельном адресном пространстве виртуальной машины MQL4. Это
динамическое связывание на этапе выполнения.
В этом случае большой оверхед на первом вызове, так как происходит
создание отдельной копии виртуальной машины, наследование
окружения от родительского скрипта, подгрузка библиотеки EX4,
ее инициализация и связывание функций. Последующие вызовы импортированных
функций работают быстро, но все равно медленнее, чем простой
"call XXXX". Импорт функций из DLL библиотек работает чуть проще
и быстрее, чем импорт из EX4.
Если я Вас правильно понял - при компиляции внутри #include прописывается
конкретный путь к вызываемой через него библиотеке и за счет
этого повышается скорость обращения?
Нет, включается код в программу как будто бы вы его там написали.
Исходный код. И при компиляции получается полностью самодостаточная
программа, за одним исключением - исполняться может только в
среде терминала.
А когда делаем #import этого не происходит и библиотеку надо тоже
предоставлять.
Мне больше нравится #include. Больше гибкости и меньше думать. Если
конечно DLL не использовать, там без этого не обойтись.
А почему компилятор ругается , что не опознает код, если в #include
вставляшь исполняемый скрипт? Хотя затем советник работает
с этим файлом корректно.
Есть два варианта #include <my.mq4> или #include "my.mq4", но файл должен
находиться в папке include. Проблема может быть с переменными, объявленными
во включемом файле. Но тогда работать не должно.
Так значит чтобы подключаемый файл вкомпилился в самого эксперта
нужно писать #include "my.mq4" и файл my.mq4 в папке include? в таком случае
необходимо будет только файл самого эксперта? в него будут вкомпилены
все подключаемые библиотеки и их вызов не будет сказываться
на скорости выполнения вызова ф-ий из них.
Командная строка #include может встречаться в любом месте программы, но обычно все включения
размешаются в начале файла исходного текста. Формат вызова:
#include <имя_файла> #include "имя_файла";
Примеры:
#include <WinUser32.mqh> #include "mylib.mqh"
Препроцессор заменяет строку #include <имя_файла> содержимым файла WinUser32.mqh. Угловые скобки обозначают, что файл WinUser32.mqh будет взят из стандартного каталога (обычно это каталог_терминала\experts\include). Текущий каталог не просматривается.
Если имя файла заключено в кавычки, то поиск производится в текущем
каталоге (в котором содержится основной файл исходного текста).
Cтандартный каталог не просматривается.
Первый вызов функции из внешней библиотеки требует загрузки и инициализации этой библиотеки практически как вызов из DLL. Это занимает существенное время. Последующие вызовы уже будут работать быстро. Попробуйте провести замеры, отбросив первый вызов.
В любом случае, вызов из библиотек будет медленнее MQL4 кода, подключенного через #include.
Внимательно прочитал пояснения ,но не понял одного - как получается более быстрый вызов через #include , если этот файл по структуре внутри также вызывает библиотеку.
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
В этом случае большой оверхед на первом вызове, так как происходит создание отдельной копии виртуальной машины, наследование окружения от родительского скрипта, подгрузка библиотеки EX4, ее инициализация и связывание функций. Последующие вызовы импортированных функций работают быстро, но все равно медленнее, чем простой "call XXXX". Импорт функций из DLL библиотек работает чуть проще и быстрее, чем импорт из EX4.
Разница огромная:
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
В этом случае большой оверхед на первом вызове, так как происходит создание отдельной копии виртуальной машины, наследование окружения от родительского скрипта, подгрузка библиотеки EX4, ее инициализация и связывание функций. Последующие вызовы импортированных функций работают быстро, но все равно медленнее, чем простой "call XXXX". Импорт функций из DLL библиотек работает чуть проще и быстрее, чем импорт из EX4.
Если я Вас правильно понял - при компиляции внутри #include прописывается конкретный путь к вызываемой через него библиотеке и за счет этого повышается скорость обращения?
Разница огромная:
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
В этом случае большой оверхед на первом вызове, так как происходит создание отдельной копии виртуальной машины, наследование окружения от родительского скрипта, подгрузка библиотеки EX4, ее инициализация и связывание функций. Последующие вызовы импортированных функций работают быстро, но все равно медленнее, чем простой "call XXXX". Импорт функций из DLL библиотек работает чуть проще и быстрее, чем импорт из EX4.
Если я Вас правильно понял - при компиляции внутри #include прописывается конкретный путь к вызываемой через него библиотеке и за счет этого повышается скорость обращения?
Нет, включается код в программу как будто бы вы его там написали. Исходный код. И при компиляции получается полностью самодостаточная программа, за одним исключением - исполняться может только в среде терминала.
А когда делаем #import этого не происходит и библиотеку надо тоже предоставлять.
Мне больше нравится #include. Больше гибкости и меньше думать. Если конечно DLL не использовать, там без этого не обойтись.
Разница огромная:
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
В этом случае большой оверхед на первом вызове, так как происходит создание отдельной копии виртуальной машины, наследование окружения от родительского скрипта, подгрузка библиотеки EX4, ее инициализация и связывание функций. Последующие вызовы импортированных функций работают быстро, но все равно медленнее, чем простой "call XXXX". Импорт функций из DLL библиотек работает чуть проще и быстрее, чем импорт из EX4.
Если я Вас правильно понял - при компиляции внутри #include прописывается конкретный путь к вызываемой через него библиотеке и за счет этого повышается скорость обращения?
Нет, включается код в программу как будто бы вы его там написали. Исходный код. И при компиляции получается полностью самодостаточная программа, за одним исключением - исполняться может только в среде терминала.
А когда делаем #import этого не происходит и библиотеку надо тоже предоставлять.
Мне больше нравится #include. Больше гибкости и меньше думать. Если конечно DLL не использовать, там без этого не обойтись.
А почему компилятор ругается , что не опознает код, если в #include вставляшь исполняемый скрипт? Хотя затем советник работает с этим файлом корректно.
Разница огромная:
В этом случае нет никаких оверхедов на вызов функций. Форма вызова проста - "call XXXX".
В этом случае большой оверхед на первом вызове, так как происходит создание отдельной копии виртуальной машины, наследование окружения от родительского скрипта, подгрузка библиотеки EX4, ее инициализация и связывание функций. Последующие вызовы импортированных функций работают быстро, но все равно медленнее, чем простой "call XXXX". Импорт функций из DLL библиотек работает чуть проще и быстрее, чем импорт из EX4.
Если я Вас правильно понял - при компиляции внутри #include прописывается конкретный путь к вызываемой через него библиотеке и за счет этого повышается скорость обращения?
Нет, включается код в программу как будто бы вы его там написали. Исходный код. И при компиляции получается полностью самодостаточная программа, за одним исключением - исполняться может только в среде терминала.
А когда делаем #import этого не происходит и библиотеку надо тоже предоставлять.
Мне больше нравится #include. Больше гибкости и меньше думать. Если конечно DLL не использовать, там без этого не обойтись.
А почему компилятор ругается , что не опознает код, если в #include вставляшь исполняемый скрипт? Хотя затем советник работает с этим файлом корректно.
Есть два варианта #include <my.mq4> или #include "my.mq4", но файл должен находиться в папке include. Проблема может быть с переменными, объявленными во включемом файле. Но тогда работать не должно.
Так значит чтобы подключаемый файл вкомпилился в самого эксперта нужно писать #include "my.mq4" и файл my.mq4 в папке include? в таком случае необходимо будет только файл самого эксперта? в него будут вкомпилены все подключаемые библиотеки и их вызов не будет сказываться на скорости выполнения вызова ф-ий из них.
Есть два варианта #include <my.mq4> или #include "my.mq4",
Скажите чем отличаются два этих метода ? в ковычка или в <>
У меня кстате не заработала конструкция #include "my.mq4" ( в кавычках)
Командная строка #include может встречаться в любом месте программы, но обычно все включения размешаются в начале файла исходного текста. Формат вызова:
Примеры:
Препроцессор заменяет строку #include <имя_файла> содержимым файла WinUser32.mqh. Угловые скобки обозначают, что файл WinUser32.mqh будет взят из стандартного каталога (обычно это каталог_терминала\experts\include). Текущий каталог не просматривается.
Если имя файла заключено в кавычки, то поиск производится в текущем каталоге (в котором содержится основной файл исходного текста). Cтандартный каталог не просматривается.