Что лучше использовать?

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

Для работы создана структура в которой параметры открытых ордеров. Ордеров ... не один...

Вариант 1:

Создать массив myStruct arr[] и работать с ним

Но сколько будет занято памяти??? Ну скажем на десяток ордеров.

Вариант 2:

Создать переменную myStruct prop и писать её в файл FileWriteStruct(), получается 100 байт.

Скорость записи не больше 16 миллисекунд. Чаще GetTickCount() показывает 0, даже очень странно. Чтение не дольше записи.


Сейчас сделано по варианту 2. Но почему-то тест идёт очень медленно не смотря на то, что от начала до конца кода GetTickCount() показывает не более 24 миллисекунд.


Так идёт замер скорости выполнения кода.

void OnTick()
{
  uint _start = GetTickCount();

// Здесь весь код

   static uint time = 0;
  time = MathMax(GetTickCount()-_start, time);

 Comment("GetTickCount ", time);
 

А что за параметры хранить собрались? Почему бы не работать с ордерами непосредственно? - Выделил ордер, посмотрел параметры.

24 миллисекунды на одно действие это очень много. Еще неправильно скорость меряете. Надо закрутить цикл этак на 1000 повторений, и мерить длительность работы всего цикла. Надо бы в сравнении с чем-то. 

Объем массива - незначительный, чтобы об этом беспокоиться.  

 
Alexey Viktorov:

Для работы создана структура в которой параметры открытых ордеров. Ордеров ... не один...

Вариант 1:

Создать массив myStruct arr[] и работать с ним

Но сколько будет занято памяти??? Ну скажем на десяток ордеров.

Вариант 2:

Создать переменную myStruct prop и писать её в файл FileWriteStruct(), получается 100 байт.

Скорость записи не больше 16 миллисекунд. Чаще GetTickCount() показывает 0, даже очень странно. Чтение не дольше записи.

Сейчас сделано по варианту 2. Но почему-то тест идёт очень медленно не смотря на то, что от начала до конца кода GetTickCount() показывает не более 24 миллисекунд.

Так идёт замер скорости выполнения кода.

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

Для этой стратегии важно помнить цену по которой поставлен был отложник, но не цена OrderOpenPrice() уже активного ордера (позиции). Вот тут и упираемся в проскальзывания. И кроме стопа и тейка нужны ещё два уровня и ещё кое-что..., высчитывать которые при каждом обращении к ордеру, на мой взгляд, не целесообразно, а "сувать" в простой массив не хватит полей.

А для чего мне замерять среднюю скорость выполнения? Ведь мне важна максимальная, которая и выводится в комментарий. Вот в данный момент, на центовом реале показывает 47 с понедельника.

Почему ты думаешь что 24 много? Разве тики идут чаще? Если обратиться к математике, то получается 1000 (миллисекунд в секунде) разделить на 25 получится 40 тиков может быть обработано в секунду. Разве не так?

Дмитрий, я спросил о занятом объёме памяти под массив структур, а не об объёме массива. Может у тебя просто очепятка? Уточни пожалуйста.

 
Vasiliy Sokolov:
Я бы не использовал ни первый ни второй вариант. Обращаться к торговому окружению надо напрямую, и не хранить его копии в своих типах данных. Только в этом случае можно достичь высокой надежности и экономии как в расчетной части, так и в используемой памяти.

К сожалению я не смог найти другого варианта для организации учёта всех групп ордеров. То-есть в один момент может быть открыто несколько групп. В группе ордера связаны между собой и закрываются/удаляются одновременно, но не могут никак влиять на ордера другой группы. Ну а коли пришлось организовывать что-то для хранения параметров по которым определяется принадлежность группе, то и остальные параметры ордера я засунул в структуру.

Магик не спасает. У меня не получилось засунуть в него № колена мартина и ещё несколько нужных параметров, а комментарий ордера вообще не вариант.

 

Глобальные переменные подойдут. В имени переменной в начале имя советника, символ, магик, потом тикет и еще какая-нибудь приставочка (ну или приставочка, потом тикет). 

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

Нету опечатки. Смотрите сколько ценовые данные занимают, сколько обычный индикатор занимает памяти. Массив для ордеров это мелочь незаметная. 

 
Alexey Viktorov:

...№ колена мартина...

Это можно в комментарий ордера. 
 
Dmitry Fedoseev:
Это можно в комментарий ордера. 

Неее, Дмитрий комментарий ордера вообще не вариант.

Ну тогда придётся терпеть такую скорость тестирования. Или в момент активного "интузязизьма" перепишу с использованием массива структур и проверю как изменится скорость тестирования.

 
Alexey Viktorov:

Неее, Дмитрий комментарий ордера вообще не вариант.

Ну тогда придётся терпеть такую скорость тестирования. Или в момент активного "интузязизьма" перепишу с использованием массива структур и проверю как изменится скорость тестирования.

Почему это комментарий не вариант?

Почему глобальная переменная не подходит? 

Это вы о надежности беспокоитесь? Тогда чем хорош массив, если после перезапуска советника или терминала все данные пропадут?

 
Dmitry Fedoseev:

Почему это комментарий не вариант?

Почему глобальная переменная не подходит? 

Это вы о надежности беспокоитесь? Тогда чем хорош массив, если после перезапуска советника или терминала все данные пропадут?

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

А GV не нравится тем-же, чем не получается в этом случае использовать магик.

 
Alexey Viktorov:

...

А GV не нравится тем-же, чем не получается в этом случае использовать магик.

Дык глобальных переменных может быть несколько к одному ордеру привязано.
12345
Новый комментарий
Причина обращения: