Мой подход. Ядро - Движок. - страница 84

Новый комментарий
 
Maxim Kuznetsov:

И да, парсинг текстов на MQL то ещё удовольствие :-) Ну не предназначен он для обработки текстов. То есть можно, но это @опа..

Массивы, приказы - вот  стезя MQL

Об этом и речь... :)

 
Nikolai Semko:

Универсальность - часто синоним тормознутости, а со стрингами тем более.
Приведу один пример.

Я как-то занимался парсингом строки, полученной с криптобиржи с помощью WebRequest. И осуществлял парсинг через библиотеку Сергеева JSON, портированную им из "скоростной библиотеки C++". И обратил внимание, что скорость какая-то ну очень неудовлетворительная. Там как раз все осуществлялось через "универсальные" строки.

Я понял что причина низкой скорости - это стринги и мне захотелось уйти использования стринг-функций и я написал функцию парсинга непосредственно из массива uchar. Результат меня весьма удивил. Моя скорость парсинга оказалась.... (барабанная дробь) в 800 раз выше. Если через JSON парсинг всей строки занимал 0.3 секунды, то через мою функцию меньше пол миллисекунды.

Вот здесь  есть пример моего парсинга через массив uchar.

Суть твоего предложения в следующем:

  1. Берем строку (640 символов), посылаем в функцию StringToChar();
  2. Получаем массив и сохраняем его в ресурсе.
  3. Получаем содержание ресурса на второй стороне с помощью ResourceReadImage() во второй массив.
  4. Посылаем второй массив в CharArrayToString() и получаем конечную строку.
  5. Далее, разбиваем строку по разделителю и записываем значения параметров в ядро.

Я изначально хотел использовать МТ-объекты для передачи строк.

  1. Берем строку (640 символов), и разбиваем на части по 64 символа.
  2. Делаем цикл по объектам связи и записываем части строки в их описание.
  3. На второй стороне, делаем цикл по объектам связи, получаем части строки и каждую часть разбиваем по разделителю, извлекая номер параметра и значение.
  4. Записываем значения параметров в ядро.

Мне изначально показался быстрее второй вариант. 

Когда работаешь с таким количеством задач, как я, приходится рассчитывать на интуицию при выборе решения. Жизни не хватит все досканально проверять. Нужна либо комманда, либо отменное чутье при выборе направления решений. И конечно, приходится жертвовать профессионализмом и мириться с пробелами в знаниях. Иначе, останется копошиться с поделками (пусть и профессионально копошиться) и уже никогда не закончить мега-проект. Это реальность.

 
Реter Konow:

Суть твоего предложения в следующем:

  1. Берем строку (640 символов), посылаем в функцию StringToChar();
  2. Получаем массив и сохраняем его в ресурсе.
  3. Получаем содержание ресурса на второй стороне с помощью ResourceReadImage() во второй массив.
  4. Посылаем второй массив в CharArrayToString() и получаем конечную строку.
  5. Далее, разбиваем строку по разделителю и записываем значения параметров в ядро.

совсем не так.
пока занят - нет времени объяснять.

если ты подробно разберешь мой код, да так чтобы не осталось белых пятен, то сделаешь для себя очень много открытий. 
ЗЫ. Только без применения отладчика разобраться будет гораздо сложнее. Не знаю, стал ли ты пользоваться им или до сих пор не используешь этот важный инструмент.

 
Nikolai Semko:

...

если ты подробно разберешь мой код, да так чтобы не осталось белых пятен, то сделаешь для себя очень много открытий. 
ЗЫ. Только без применения отладчика разобраться будет гораздо сложнее. Не знаю, стал ли ты пользоваться им или до сих пор не используешь этот важный инструмент.

Завтра внимательно рассмотрю твой код. (Не забывай про часовые пояса)

Может действительно, открою для себя что то новое. ))

 

Любая структура - строка. Массив структур - массив строк с описанием их формата. Класс - структура и методы, реализация класса - массив реализаций (простите мой французский). 

Не нужно ничего преобразовывать до последнего момента. Тут везде участвуют только строки. Просто, они нормализованы: кто-то занимает 2, или 4 байта, а кто-то - 1, вот и надо выравнивать. 

ЗЫ Впервые применил этот подход приблизительно в 1993 году, СУБД Clarion. Все работало очень быстро. 

 
Алексей Тарабанов:

Любая структура - строка. Массив структур - массив строк с описанием их формата. Класс - структура и методы, реализация класса - массив реализаций (простите мой французский). 

Не нужно ничего преобразовывать до последнего момента. Тут везде участвуют только строки. Просто, они нормализованы: кто-то занимает 2, или 4 байта, а кто-то - 1, вот и надо выравнивать. 

ЗЫ Впервые применил этот подход приблизительно в 1993 году, СУБД Clarion. Все работало очень быстро. 

примерно в одно и то-же время с одним и тем-же :-) Одна школа... кстати СУБД была неплоха и во многом опередила время.

PS/ есть горячо временами любимый тикль, опостериорно на уровне концепции "всё есть строка/текст". Скорость правда на уровне питона

 
Реter Konow:

Завтра внимательно рассмотрю твой код. (Не забывай про часовые пояса)

Может действительно, открою для себя что то новое. ))

может это еще пригодиться

Пример индикатора, в котором используются ресурсная переменная на примере double, которая при смене ТФ не переинициализирует свое значение. Более удобная альтернатива глобальным переменным терминала. Таким же образом как глобальные можно использовать  различные структуры данных и массивы этих структур.

Файлы:
Variable.mqh  7 kb
TestResVar.mq5  3 kb
 
Nikolai Semko:

может это еще пригодиться

) 

 
Реter Konow:
Ради интереса я попробую вариант с юнион. И с CharArrayToString и StringToCharArray. Хотя, чутье мне подсказывает, что врядли это будет быстрее, чем общение через описание МТ-объектов. Но, может ошибаюсь. Посмотрим...

Петр, ты изначально сделал дичь, а теперь рассуждаешь о производительности обмена сообщениями в рамках своей дичи. Ты пойми: string - это просто удобная ***, не больше. Любые данные на самом деле это просто набор байтов в памяти. Вот тебе и советуют работать с байтами напрямую, а ты как всегда упрямишся, не понимая что тот же string это тот же массив байтов. Поэтому на конвертации string в массив uchar ты ничего не теряешь, а вот при парсинге строки твоя производительность реально проседает. Поэтому вся твоя интуиция - это вообще мимо.   

 
Vasiliy Sokolov:

1. Петр, ты изначально сделал дичь, а теперь рассуждаешь о производительности обмена сообщениями в рамках своей дичи.

2.Ты пойми: string - это просто удобная ***, не больше. Любые данные на самом деле это просто набор байтов в памяти. Вот тебе и советуют работать с байтами напрямую, а ты как всегда упрямишся, не понимая что тот же string это тот же массив байтов. Поэтому на конвертации string в массив uchar ты ничего не теряешь, а вот при парсинге строки твоя производительность реально проседает.

3. Поэтому вся твоя интуиция - это вообще мимо.   

1. "Дичь" - в данном случае, это твое понимание, а не то, что я сделал. Потребовалось 75 страниц, чтобы ты понял о чем речь и что такое движок. Пойми: Изъяны и ошибки не характеризуют сущность. Никакая форма сущности не характеризует саму сущность. Как твоя одежда, не определяет что ты за человек. Только неправильное мышление судит о целом по частности.  

2. Это и так мне понятно. А действительно ли будет выйгрыш в скорости с использованием функции StringToChar я сегодня проверю.

3. Я каждый день проверяю свою интуицию. Каждый день в ней сомневаюсь. И это правильно. Если она подводит, то нужно руководствоваться Разумом. Но, Разум слишком ограничен, высокомерен и глуп, чтобы на него можно было всегда полагаться. Поэтому, интуиция - это единственная альтернатива. Если ты понимаешь о чем я говорю...

1...777879808182838485868788899091...184
Новый комментарий
Причина обращения: