MetaLang - трансляция - память - кэш виндузов и коментарии в экспертах
1. Использованием виртуальной памяти занимается сама операционка. Если есть физическая память (тем более 4 гб), то она и используется.
2. Нет. Выигрыша в памяти это не даст. MQL4 - компилируемый язык, который генерирует ассемблерный код. В EX4 нет никаких следов исходного кода, кроме внешних extern переменных и строковых констант.
3. Если терминал не выгружается до конца, значит в нем есть подвисший процесс из-за какого-то эксперта. Если эксперт или индикатор использует DLL, то наверняка дело именно в некорректной работе с DLL.
Можете выслать код эксперта (MQ4 / EX4) на stringo AT metaquotes . ru для тестов? Код гарантированно удалим после проверок.
4. Это радует.
5. К сожалению, руки не дошли - попробуем в 211 билде улучшить режим контрасного.
2. Нет. Выигрыша в памяти это не даст. MQL4 - компилируемый язык, который генерирует ассемблерный код. В EX4 нет никаких следов исходного кода, кроме внешних extern переменных и строковых констант.
3. Если терминал не выгружается до конца, значит в нем есть подвисший процесс из-за какого-то эксперта. Если эксперт или индикатор использует DLL, то наверняка дело именно в некорректной работе с DLL.
Можете выслать код эксперта (MQ4 / EX4) на stringo AT metaquotes . ru для тестов? Код гарантированно удалим после проверок.
4. Это радует.
5. К сожалению, руки не дошли - попробуем в 211 билде улучшить режим контрасного.
1. Трансляция идет в два этапа. Загрузка файлов и собственно трансляция. Транслятор
при загрузке потребляет более 2Ггб - получает единый файл кодов. Затем приступает собственно к трансляции - на этом этапе потребление памяти 200-300 Мб. Моя проблема именнов в первом этапе - этапе загрузки файлов с исходным кодом в Транслятор. Убрал коментарии - хорошо расширился. Но перспектива неважная - это примерно 1\20 объема проекта.
Ближайшая идея - разрубить программу на 50-100 групповых экспертов. 1
А.СКОЛЬКО ЭКСПЕРТОВ (МАКС.ЧИСЛО) ДОПУСТИМО ОДНОВРЕМЕННО ЛОГИНИТЬ НА РЕАЛЬНЫЙ
СЧЕТ ПО ГЛАВНОМУ ПАРОЛЮ ПО ОДНОЙ ВАЛЮТНОЙ ПАРЕ ИЗ РАЗНЫХ ЭКЗЕМПЛЯРОВ
МЕТАТРЕЙДЕРА (естественно, с развязкой по магическому номеру)??
Б.ВСЕ ЖЕ ВОПРОС. Логика моей программы позволяет не проводить развязку
ордеров разных экспертов сидящих на одной валютной паре. Мне удалось бы
сэкономить время, если бы вы прокоментировали: КАК ОТРАЗИТСЯ НА ЖУРНАЛЕ
ТОРГОВ ТЕРМИНАЛА СИТУАЦИЯ ОТКРЫТИЯ ОРДЕРА ИЗ ОДНОГО ТЕРМИНАЛА С ПОСЛЕДУЮЩИМ
ЗАКРЫТИЕМ ИЗ ДРУГОГО, ПРИ ЭТОМ ТЕРМИНАЛЫ ОДНОВРЕМЕННО ПОДКЛЮЧЕНЫ ПО
ГЛАВНОМУ ПАРОЛЮ К РЕАЛЬНОМУ СЧЕТУ.
2. Да, судя по падению потребления памяти после загрузки до 200-300
Мб - коментарии на этапе собственно трансялции уже удалены.
3. Терминал не выгружается до конца только в ситуации запуска его из-под редактора и последующего закрытия терминала: редактор-терминал-закрытие терминала-выход в редактор. При стандартной схеме запуска - терминал-редактор-терминал - выгрузка без замечаний. Я специально указал схему, при которой возникают подвисшие ресурсы.
Это просто информация для Вас. Лично мне это в работе не мешает. DLL не использую.
С уважением,
Александр Панков.
при загрузке потребляет более 2Ггб - получает единый файл кодов. Затем приступает собственно к трансляции - на этом этапе потребление памяти 200-300 Мб. Моя проблема именнов в первом этапе - этапе загрузки файлов с исходным кодом в Транслятор. Убрал коментарии - хорошо расширился. Но перспектива неважная - это примерно 1\20 объема проекта.
Ближайшая идея - разрубить программу на 50-100 групповых экспертов. 1
А.СКОЛЬКО ЭКСПЕРТОВ (МАКС.ЧИСЛО) ДОПУСТИМО ОДНОВРЕМЕННО ЛОГИНИТЬ НА РЕАЛЬНЫЙ
СЧЕТ ПО ГЛАВНОМУ ПАРОЛЮ ПО ОДНОЙ ВАЛЮТНОЙ ПАРЕ ИЗ РАЗНЫХ ЭКЗЕМПЛЯРОВ
МЕТАТРЕЙДЕРА (естественно, с развязкой по магическому номеру)??
Б.ВСЕ ЖЕ ВОПРОС. Логика моей программы позволяет не проводить развязку
ордеров разных экспертов сидящих на одной валютной паре. Мне удалось бы
сэкономить время, если бы вы прокоментировали: КАК ОТРАЗИТСЯ НА ЖУРНАЛЕ
ТОРГОВ ТЕРМИНАЛА СИТУАЦИЯ ОТКРЫТИЯ ОРДЕРА ИЗ ОДНОГО ТЕРМИНАЛА С ПОСЛЕДУЮЩИМ
ЗАКРЫТИЕМ ИЗ ДРУГОГО, ПРИ ЭТОМ ТЕРМИНАЛЫ ОДНОВРЕМЕННО ПОДКЛЮЧЕНЫ ПО
ГЛАВНОМУ ПАРОЛЮ К РЕАЛЬНОМУ СЧЕТУ.
2. Да, судя по падению потребления памяти после загрузки до 200-300
Мб - коментарии на этапе собственно трансялции уже удалены.
3. Терминал не выгружается до конца только в ситуации запуска его из-под редактора и последующего закрытия терминала: редактор-терминал-закрытие терминала-выход в редактор. При стандартной схеме запуска - терминал-редактор-терминал - выгрузка без замечаний. Я специально указал схему, при которой возникают подвисшие ресурсы.
Это просто информация для Вас. Лично мне это в работе не мешает. DLL не использую.
С уважением,
Александр Панков.
1. Пояснение - в дополнение -в извинение и тд. Иногда ситуация кажется патовой и приходят в голову кривые идеи. Отказаться от проекта самообечающейся программы, имеющей трудовую биржу с милионом экспертов - советников, мз которых на работу по реальному счету принимают по трудовой книжке - истории ордеров каждого из них - ТРУДНО. Но выход есть всегда, и он, как всегда найден.
От кривызны в сторону группового изнасилования счета экспертами отказался. Правда за счет поступления принцыпами: пришлось все же воспользоваться чтением файла Советников в процессе выставления ордера. Это может повлечь задержки в выставления ордера, проскальзывания и т.п. Файл Советников - вынесенный из программы офис советников, который не может потянуть при загрузке транслятор.
Пока что такое решение - золотая середина между использованием скриптов ( что подразумевало бы разбиение программы с соответствующим скрупулезным сопровождением и отладкой) и групповухой экспертов над счетом.
Тем не менее хотелось бы получить ответы на вопросы 1-А и 1-Б. ъ
Простое одновременное подключение к реалу нескольких терминалов по главному паролю уже провел двумя экспертами. Терминал не воозмутился и спокойно допустил.
Но как это будет себя вести при выставлении ордеров??? Одновременное открытие ??? Открытие из одного, а закрытие из другого??? Теперь эти вопросы носят только перспектиный характер - если потребуется уехать и работать удаленно внакладку с
с домашним стационарным терминалом.
Заранее благодарен,
Александр Панков.
От кривызны в сторону группового изнасилования счета экспертами отказался. Правда за счет поступления принцыпами: пришлось все же воспользоваться чтением файла Советников в процессе выставления ордера. Это может повлечь задержки в выставления ордера, проскальзывания и т.п. Файл Советников - вынесенный из программы офис советников, который не может потянуть при загрузке транслятор.
Пока что такое решение - золотая середина между использованием скриптов ( что подразумевало бы разбиение программы с соответствующим скрупулезным сопровождением и отладкой) и групповухой экспертов над счетом.
Тем не менее хотелось бы получить ответы на вопросы 1-А и 1-Б. ъ
Простое одновременное подключение к реалу нескольких терминалов по главному паролю уже провел двумя экспертами. Терминал не воозмутился и спокойно допустил.
Но как это будет себя вести при выставлении ордеров??? Одновременное открытие ??? Открытие из одного, а закрытие из другого??? Теперь эти вопросы носят только перспектиный характер - если потребуется уехать и работать удаленно внакладку с
с домашним стационарным терминалом.
Заранее благодарен,
Александр Панков.
1А. Сколько угодно.
2Б. Все терминалы равноценны и никак друг другу не мешают. Вы можете без проблем (при правильной логике программ) реализовать логику открытия на одном, а закрытие на другом терминале.
Попробуйте использовать динамически подключаемые библиотеки через #include "libXXX.EX4" с выносом части функционала в них. Тем самым Вы уменьшите тело основного кода и перекомпиляции не будут занимать столько места.
2Б. Все терминалы равноценны и никак друг другу не мешают. Вы можете без проблем (при правильной логике программ) реализовать логику открытия на одном, а закрытие на другом терминале.
Попробуйте использовать динамически подключаемые библиотеки через #include "libXXX.EX4" с выносом части функционала в них. Тем самым Вы уменьшите тело основного кода и перекомпиляции не будут занимать столько места.
"динамически подключаемые библиотеки" - t.e. допустимо подключать уже скомпилированные файлы. Стыжусь, но до сих пор не вычитал и не проверял эту возможность.
ОГРОМНОЕ СПАСИБО за идею.
Буду думать где и когда ее приложить.
С уважением,
Александр Панков.
ОГРОМНОЕ СПАСИБО за идею.
Буду думать где и когда ее приложить.
С уважением,
Александр Панков.
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
С самой трансляцией проблем нет. Проблема - первичная загрузка текстов исходников в МetaLang. Как заставить его использовать виртуальную память виндов?
2. Есть ли не описанные ключи трансляции, позволяющие сразу, при загрузке файлов в МetaLang, отсекать строки коментариев.
3. В качестве доп.информации. Не знаю, на сколько это допустимо и коректно, но я частенько запускаю не терминал, а затем МетаEditor, а сразу - МетаEditor - для редактирования экспертов.
При этом наблюдается некорректное освобождение памяти и ресурсов, которое выражается следующим образом.
а. Терминал не запущен.
Запускаем MetaEditor.
Компилируемся - Запускается МетаLang.
Откомпилировались - нажимаем пипку Terminal.
При запуске терминала - автоматом - запускается повторно МетаLang.
Пока МетаLang не отработает - оттранслированный эксаперт не
будет доступен.
Ждем пока отработает вторичный МетаLang, чтобы не дергать лишний
раз процессы.
Дождались - МетаLang - закончил, в запущенном Терминале - эксперт доступен.
Закроем окно терминала.
Вернемся в окно редактора.
Подготовим следующую версию эксперта.
Повторим процесс трансляции и вызова терминала.
РЕЗУЛЬТАТЫ:
-- в менеджере задач можно увидеть как минимум один бесхозно
брошенный процесс Терминал.
-- с каждой новой трансляцией и последующим вызовом терминала - число
брошенных бесхозных процессов растет.
-- каждый из них удерживает до 16мБ памяти.
-- на 5-6 брошенном - может наступить ступорт - терминал из редактора не будет запущен. Запуск произойдет автоматом, если в менеджере задач убить бомжей.
4. В качестве доп.инфо.
В 210 билде получилась наилучшая генерация тиков, предусматривающая наиболее проблемные ситуации тикового уровня. До сих пор, для проверки этих ситуации приходилось последовательно прогонять тесты через билды 205-208. Теперь хватает прогона только под 210.
5. Напоминание. Поддержите - Черно-белый контрастный режим в Виндузах. Черный шрифт на черном фоне - во входных парметрах эксперта, в полях выбора, отчетов тестера и оптимизатора. Наилучший вариант - сделать возможность индивидуальной установки цветов - как в MetaEditor.
С уважением, Александр Панков.