5 Знаков - страница 3

Новый комментарий
 
Boris:
Проверьте и просто Point без скобок и подчёркивания впереди! Тут явно видна экономия на лишних знаках!

Смысла уже не вижу, но Вы можете легко их повторить.

Тем более, что просто Point - первый кандидат на репрессии или по крайней мере на "не использовать никогда", ибо устарело и не кросплатформенно (компилятор MQL5 на такое плюнет в лицо).


Karputov Vladimir:
Точность замеров GetTickCount примерно 16 мс. Поэтому все замеры помещаются в зону погрешности.

Спасибо за ценную информацию, про 16 мс не знал.

 
Sergey Eremin:

Смысла уже не вижу, но Вы можете легко их повторить.

Тем более, что просто Point - первый кандидат на репрессии или по крайней мере на "не использовать никогда", ибо устарело и не кросплатформенно (компилятор MQL5 на такое плюнет в лицо).

МТ5 не пользую! 

И другой вопрос, стилистика! Которая экономит на пропусках (X=Y, X>Y и пр.), всё лепит в неразборчивую кучу, а на бесконечных лестницах закрывающих скобок расточительствует. 

Я пишу X = Y, X > Y и пр., и закрывающие скобки располагаю в линию } } } } } } } } } } }, чем увеличиваю обзор кода! 

А может, программистам платят полинейно?! 

 
Sergey Eremin:

...

Спасибо за ценную информацию, про 16 мс не знал.

Это из практических замеров на практике. Истина не в последней инстанции.

Добавлено: для более точных замеров (микросекунд) есть GetMicrosecondCount 

 
Karputov Vladimir:

Это из практических замеров на практике. Истина не в последней инстанции.

Добавлено: для более точных замеров (микросекунд) есть GetMicrosecondCount 

И Ренат говорил о погрешности в 16 мс. как минимум два раза. По поиску, вижу, что и в 2013 г., к примеру.

Но приведу ссылку на 2015 г.: https://www.mql5.com/ru/forum

Другие так же упоминали о такой погрешности. Сама на практике замечала то, из чего можно сделать вывод об этой погрешности.

Ссылку выше привожу, поскольку на следующей странице есть предупреждение Рената об осторожности при замерах: https://www.mql5.com/ru/forum (к чему это он написал см. по ссылке там выше по тексту, привожу это здесь, чтобы предупредить на всякий случай).

 
Boris:

МТ5 не пользую! 

И другой вопрос, стилистика! Которая экономит на пропусках (X=Y, X>Y и пр.), всё лепит в неразборчивую кучу, а на бесконечных лестницах закрывающих скобок расточительствует. 

Я пишу X = Y, X > Y и пр., и закрывающие скобки располагаю в линию } } } } } } } } } } }, чем увеличиваю обзор кода! 

А может, программистам платят полинейно?! 

Вы не пользуете (возможно лишь пока), а другие пользуют.

Ну а стилистика это уже вообще религия и я, к сожалению, вообще не понял, к чему эти Ваши слова. Возможно Вы пока никак не участвовали в командной разработке, но если это случится (и займёт достаточно много времени), то вероятно прочувствуете что придираться к чужим стилям это... непрофессионально. Есть более значимые вещи, на которые стоит тратить усилия. Особенно интересно было бы посмотреть за эволюцией Вашей категоричности если бы Вы попали в командную разработку, где применяется какой-нибудь общепринятый стандарт стилистики кода, а не "как хочу так и пишу" :)

 
Sergey Eremin:

Вы не пользуете (возможно лишь пока), а другие пользуют.

Ну а стилистика это уже вообще религия и я, к сожалению, вообще не понял, к чему эти Ваши слова. Возможно Вы пока никак не участвовали в командной разработке, но если это случится (и займёт достаточно много времени), то вероятно прочувствуете что придираться к чужим стилям это... непрофессионально. Есть более значимые вещи, на которые стоит тратить усилия. Особенно интересно было бы посмотреть за эволюцией Вашей категоричности если бы Вы попали в командную разработку, где применяется какой-нибудь общепринятый стандарт стилистики кода, а не "как хочу так и пишу" :)

Стилистика, стилизация должна тоже служить экономии тех миллисекунд, о которых так пекутся в этой теме, потому привёл пример расточительства, когда для одной скобки } читающему фунционалу надо пробежать десятки пропусков. 

Для меня программирование хобби, продолжающее моё увлечение развитием творческих идей в другой области моей проф. деятельности, которая была связана с "командами" только после завершения мною очередной работы.

 
Karputov Vladimir:

Это из практических замеров на практике. Истина не в последней инстанции.

Добавлено: для более точных замеров (микросекунд) есть GetMicrosecondCount 

Спасибо ещё раз! При применении этой функции результаты такие (10 замеров по 10 проходов по миллиону итераций в циклах):

_Point равно Point() 0 раз; _Point быстрее Point() 3 раз; _Point медленнее Point() 7 раз
_Point равно Point() 0 раз; _Point быстрее Point() 2 раз; _Point медленнее Point() 8 раз
_Point равно Point() 0 раз; _Point быстрее Point() 0 раз; _Point медленнее Point() 10 раз
_Point равно Point() 0 раз; _Point быстрее Point() 4 раз; _Point медленнее Point() 6 раз
_Point равно Point() 0 раз; _Point быстрее Point() 1 раз; _Point медленнее Point() 9 раз
_Point равно Point() 0 раз; _Point быстрее Point() 4 раз; _Point медленнее Point() 6 раз
_Point равно Point() 0 раз; _Point быстрее Point() 2 раз; _Point медленнее Point() 8 раз
_Point равно Point() 0 раз; _Point быстрее Point() 4 раз; _Point медленнее Point() 6 раз
_Point равно Point() 0 раз; _Point быстрее Point() 5 раз; _Point медленнее Point() 5 раз
_Point равно Point() 0 раз; _Point быстрее Point() 4 раз; _Point медленнее Point() 6 раз

Вот теперь я даже не знаю что и думать.

Неужели Point() быстрее, чем _Point, или опять вмешивается погрешность, но теперь уже у GetMicrosecondCount()?

Прошу посмотреть код, может я где-то допустил ошибку?


Код:

#property strict

void OnStart()
{
   Alert("-------");
   for(int k = 0; k < 10; k++)
   {
   string text = "";
   int equalCnt = 0;
   int fasterCnt = 0;
   int slowerCnt = 0;
   for(int j = 0; j < 10; j++)
   {
      ulong startTickCnt = GetMicrosecondCount();
      for(int i = 0; i < 1000000000; i++)
      {
         double point = _Point;
      }
      ulong endTickCnt = GetMicrosecondCount();
      
      
      ulong startTickCnt2 = GetMicrosecondCount();
      for(int i = 0; i < 1000000000; i++)
      {
         double point = Point();
      }
      ulong endTickCnt2 = GetMicrosecondCount();
      
      ulong v1 = endTickCnt - startTickCnt;
      ulong v2 = endTickCnt2 - startTickCnt2;
      if(v1 == v2)
      {
         equalCnt++;
      }
      else if(v1 < v2)
      {
         fasterCnt++;
      }
      else if(v1 > v2)
      {
         slowerCnt++;
      }      
      
      string str1 = "_Point: " + (string)v1;
      string str2 = "Point(): " + (string)v2;
      
      text = text + (string)j + ")" + str1 + " | " + str2 + " | " + "\r\n";
   }
   
   string equalCntStr = "_Point равно Point() " + (string)equalCnt + " раз";
   string fasterCntStr = "_Point быстрее Point() " + (string)fasterCnt + " раз";
   string slowerCntStr = "_Point медленнее Point() " + (string)slowerCnt + " раз";
   
   Alert(k, ")", text, "\r\n\r\n", equalCntStr,"; ",fasterCntStr,"; ",slowerCntStr);
   }
}
 
Boris:

Стилистика, стилизация должна тоже служить экономии тех миллисекунд, о которых так пекутся в этой теме, потому привёл пример расточительства, когда для одной скобки } читающему фунционалу надо пробежать десятки пропусков.

Вы ведь знаете, что компилятор игнорирует все пробелы, табуляции, переносы строк, комментарии и т.д. и на скорость выполнения конечного исполняемого файла они ну вообще никак не влияют?
 
Sergey Eremin:
Вы ведь знаете, что компилятор игнорирует все пробелы, табуляции, переносы строк, комментарии и т.д. и на скорость выполнения конечного исполняемого файла они ну вообще никак не влияют?

Гыгыгы...

Думаю он не знал. 

 
Sergey Eremin:
Вы ведь знаете, что компилятор игнорирует все пробелы, табуляции, переносы строк, комментарии и т.д. и на скорость выполнения конечного исполняемого файла они ну вообще никак не влияют?
Тогда зачем в стилизации пишется без пропусков (X=Y, X>Y и пр.)? А бесконечные лестницы растягивает коды на метры, ведь в Эдиторе помещается не более 50-ти линий! Для меня главное всё, логика, рациональность, скорость и удобство!
123456
Новый комментарий