Особенности языка mql5, тонкости и приёмы работы - страница 102
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну это вы уж перегнули ) Оно же во-первых идёт через очередь сообщений. Во-вторых, вам приходится делать какие-то дополнительные преобразования (туда и обратно). Плюс там какая-то валидация происходит.
Кстати, размер структуры не стоит прописывать явно. Для этого есть sizeof.
Наверное Вы какой-то другой код посмотрели.
ЗЫ единственное, что мне не нравиться в моем варианте: Мне пришлось удваивать размер строки для обхода нулей, т.к. ноль воспринимается как конец строки. Спинным мозгом чувствую, что есть проще решение, но не нашел. Но все равно быстрее работает.
SetWindowText/GetWindowText не через сообщения шлются?
Никаких преобразований туда-обратно нет
Ну конечно. А это что за пляски с бубнами:
SetWindowText/GetWindowText не через сообщения шлются?
А Вы об сообщениях виндоус ... Ну и что? А разве существует более быстрая альтернатива обмена данными между разными программами в виндах без самописных dll?
Я же так понимаю, что Вас задели мои слова, что мой вариант шустрый. Ну так, во-первых, я это не утверждал, а лишь предположил. А во-вторых, предположение свое подкрепил тестировочным кодом при сравнении с Memory Mapping.
А Вы, если пытаетесь опровергнуть даже предположение, то, пожалуйста, не стройте свое опроверждение только лишь на декларативных утверждениях. Я Вам очень буду благодарен, если Вы меня разубедите и укажете на более быструю реализацию обмена данными между терминалами без самописных dll.
Не исключаю, что вариант через RAM диск окажется значительно быстрее. Но это немного другая тема, так как требует установки этого RAM диска и его настройки.
Ну конечно. А это что за пляски с бубнами:
Тоже мне - бубны нашли. Это банальщина. И эта банальщина, между прочим, выполняется за 50-60 нс, когда весь блок получения структуры тика выполняется за 90 мкс (90 000 нс.), т.е эти "бубны" занимают лишь 0,06 % времени получения блока данных. Тем более я писал, что этот момент меня только и смущает в виду удвоения памяти.
А так мой вариант видится очень даже удобным, простым и шустрым для обмена небольшими структурами данных.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Библиотеки: HistoryTicks
Automated-Trading, 2018.03.29 11:09
Вау!
Я даже не знал о таких функциях, как CryptEncode и CryptDecode. Спасибо!
Поизучаю.
ЗЫ Но пока на первый взгляд это всё, конечно, высокотехнологично, но безумно медленно, ибо Функция CryptEncode выполняется на два порядка медленнее (микросекунды против десятков наносекунд) чем то, что тут назвали бубнами:
Я же так понимаю, что Вас задели мои слова, что мой вариант шустрый. Ну так, во-первых, я это не утверждал, а лишь предположил. А во-вторых, предположение свое подкрепил тестировочным кодом при сравнении с Memory Mapping.
Да я не по "шустрость", а про "не исключено, что быстрее всех существующих решений". Поэтому внёс несколько замечаний, без каких либо наездов. И эти замечания были вполне справедливы. Только вы почему-то сначала упорно отрицаете это ("наверное Вы какой-то другой код посмотрели"), а потом становитесь в позицию "ну и что!". Так что давайте всё ж отделим мух о котлет.
Во-первых, моё сообщение было написано раньше, чем вы привели ваш тестировочный код. Во-вторых, что касается MemoryMapping (а точнее - упомянутой его MQL-обёртки), я нигде и не утверждал, что это работает быстро. Более того, в ветке обсуждения этого проекта вот здесь я указывал на ошибки автора, создающие тормоза, и как их исправить. Поэтому вы если уж берётесь что-то тестировать, то тестируйте это в нативном виде, а не в виде чьих-то неправильных решений.
ЗЫ Но пока на первый взгляд это всё, конечно, высокотехнологично, но безумно медленно, ибо Функция CryptEncode выполняется на два порядка медленнее (микросекунды против десятков наносекунд) чем то, что тут назвали бубнами:
Для чего нужна скорость?
Да я не по "шустрость", а про "не исключено, что быстрее всех существующих решений". Поэтому внёс несколько замечаний, без каких либо наездов. И эти замечания были вполне справедливы. Только вы почему-то сначала упорно отрицаете это ("наверное Вы какой-то другой код посмотрели"), а потом становитесь в позицию "ну и что!". Так что давайте всё ж отделим мух о котлет.
Во-первых, моё сообщение было написано раньше, чем вы привели ваш тестировочный код. Во-вторых, что касается MemoryMapping (а точнее - упомянутой его MQL-обёртки), я нигде и не утверждал, что это работает быстро. Более того, в ветке обсуждения этого проекта вот здесь я указывал на ошибки автора, создающие тормоза, и как их исправить. Поэтому вы если уж берётесь что-то тестировать, то тестируйте это в нативном виде, а не в виде чьих-то неправильных решений.
Ок. Согласился. Заявил слишком громко.
Просто хотел сказать, что, возможно использование user32.dll вместо kernel32.dll может оказаться быстрее в вопросе связывания двух терминалов в помощью WinAPI, т.к. все реализации, которые я встречал именно использовали kernel32.dll.
Для чего нужна скорость?
Прошу прощения, не понял вопрос.
Вы спрашиваете - зачем нужна скорость обмена данными моста между терминалами?
Прошу прощения, не понял вопрос.
Вы спрашиваете - зачем нужна скорость обмена данными моста между терминалами?
Да.
Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий
Особенности языка mql5, тонкости и приёмы работы
Nikolai Semko, 2018.09.21 13:20
ЗЫ Но пока на первый взгляд это всё, конечно, высокотехнологично, но безумно медленно, ибо Функция CryptEncode выполняется на два порядка медленнее (микросекунды против десятков наносекунд) чем то, что тут назвали бубнами: