Jump to content

Рубрика: оптимизация кода и подбор железа для ускорения оптимизации советников


Recommended Posts

Programmer

Пришло в личку такое сообщение:

 

Добрый день еще раз,

 

Я понял, что только вы имеет право открывать новые темы.

 

Я хотел бы опросить опытных программистов на языке MQL как можно оптимизировать (сократить) время на оптимизацию кода советников и обсудить разные способы, как-то :

 

1) апгрейд железа в правильном направлении;

2) выбор правильного режима оптимизации;

3) написание части модулей на С++ (в отрывочных сообщениях я видел, что это якобы повышает производительность "в 20 раз", но не понял как этим воспользоваться);

 

Пожалуйста посодействуйте размещению темы.

С Ув.,

Вячеслав

 

Очень интересная и для многих актуальная тема!

Предлагаю рассмотреть упомянутые пункты.

Edited by Programmer
Link to post
Share on other sites
NoobTrader
Очень интересная и для многих актуальная тема!Предлагаю рассмотреть упомянутые пункты.

 

Спасибо большое!

 

Немного уточню по пунктам 1-3:

 

 

1) Апгрейд железа.

 

а) Например, влияет ли на скорость оптимизации объем оперативной памяти или только мощность процессора? (У меня на работе и памяти меньше и проц слабее - оптимизация сильно тормозит).

 

б) Где-то также писали, что надо отключать технологию Hypertreading на процессорах Интел. Насколько я понимаю НТ это стандарт для всех сегодняшних процессоров Интел. Получается, современные технологические решения только тормозят оптимизацию?

 

в) А увеличение числа ядер процессора или его тактовой частоты (переход на аналогичный процессор с более высокой тактовой частотой) приведет к увеличению производительности?

 

2) Выбор правильного режима оптимизации.

 

а) На форуме МQL есть несколько обсуждений и статьи по правильной оптимизации: рекомендуют проводить тщательный отбор параметров, установление критериев оптимизации, например, максимальная просадка не более 50%. Но можно ли как-то гарантировать, что установив ограничение по максимальной просадке, и получив результат, скажем, +40000 долл. на тестере, я не пропущу притом какие-то перспективные значения, с просадкой 60%, прибылью 80 000, по которым потом можно сократить просадку, оптимизируя другие критерии?

 

Иными словами есть ли какие-то способы оценки, какими должны быть ограничения при оптимизации?

 

б) Может кто-то поделится какими-то своими рецептами по установлению ограничений при оптимизации? Я пользуюсь только ограничением по просадке, ставлю его около 55%, чтобы не "потерять" интересные решения с большими прибылями и отсеять все комбинации, допускающие просадку более 55%... остальные ограничения (баланс, макс прибыль) даже не могу и придумать как эффективно использовать. Пользуется ли ими еще кто-то и как?

 

3) Использование других языков программирования.

 

а) Допустим, у меня есть ЕА с 5-6 фильтрами, функцией торговли и управления ордерами. Оптимизируется около 10 часов (!!!) на рабочем компьютере по двум параметрам. Можно ли как-то вынести в dll-ки часть кода, разрешив советнику импорт длл, и ускорит ли это оптимизацию?

Edited by NoobTrader
Link to post
Share on other sites
expforex2

Действительно тема достаточно интересная,

 

1. Если речь идет о мт4, то проц ине имеет значения, ну единственное если у Вас комп не годов 90. У меня ноут на 3 гига оперы и 2 ядерный проц, домашний рабочий комп на 6 гиг оперы я 1 ядерный проц, разницы в тетсировании нет, единственное что если система действительно загрузила всю свободную память, то тесты тормозят.

 

Поэтому кажется что память немного играет роли

 

2. Оптимизацию следует проводить по тем критериям, по котоырм Вы будете торговать на реале, напрмиер я пользуюсь такими критериями: макимальынй убыток. Хорошо реализовали оптимизацию в мт5 ,с форвардтестом. это значит что нужно проводить оптимизацю например за мая, а тесттирвоать на июне, даст более точные результаты, да и указывать большой срок оптимизации не стоит - иначе получится обычный подбор параметров.

 

3. Если в советники есть более широкие и сложные математические операции то стоит их выводить в dll- для более быстрого расчета, ведь dll использует весь компьютер, а насколько знаю мт4 - только часть.

Edited by expforex2

Ищите программиста? могу помочь..

Link to post
Share on other sites
NoobTrader

Спасибо за советы. С железом, кажется, понятно. У меня МТ4, домашний комп 3 Гига оперативки, там все вроде оптимизируется приемлемо. На работе процессор селерон Дуо какой-то всего 1.2 Мгц, и памяти 1 Гиг. Наверное, на работе все же не хватает проца, т.к. память грузится не на 100%, а примерно на 20-30%, не более.

 

Действительно тема достаточно интересная,

 

2. .... да и указывать большой срок оптимизации не стоит - иначе получится обычный подбор параметров.

 

 

по 2.: Да, горизонт (срок) оптимизации конечно сильно влияет на ее продолжительность. Но мне кажется, сокращать его не очень правильно, вот почему.

 

Мой ЕА работает на графике Н4, в среднем дает 1-2 сигнала (сделки) в неделю. Можно использовать как индикатор для ручной торговли, можно заставить его самого торговать.

 

Я пытался вручную проверить такую идею: оптимизировал два параметра например на феврале, а потом тестировал ее на марте, и т.д. вперед до настоящего времени.

 

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

 

Если же взять период хотя бы полгода, то депозит показывает несколько периодов флэта, и несколько периодов роста, просадка примемлемая вроде (менее 20%). Разве это не значит, что я нашел некие значения параметров, которые в некоторые периоды рынка будут позволять сохранять депозит, а в другие позволят его наращивать?

 

Кроме того, на работе у меня закачана история на год, дома на два года, а дома у девушки :) история на 5 месяцев. Везде оптимизируемые параметры достаточно стабильны, т.е. они не просто подогнаны, а оптимальны на периодах 2 года, год, 5 месяцев. А вот когда обрубаю срок оптимизации до 1 месяца, начинаются указанные выше проблемы со стабильностью параметров.

 

Может быть здесь имеет значение период на котором работает система? Интрадэй системы оптимизировать на месяце, а те, которые анализируют периоды Н4 и выше - на более долгих отрезках?

 

3. Если в советники есть более широкие и сложные математические операции то стоит их выводить в dll- для более быстрого расчета, ведь dll использует весь компьютер, а насколько знаю мт4 - только часть.
А на чем надо писать такие dll? С MQL я достаточно хорошо разобрался, но С++ не знаю. Какую-то конкретную версию его можете посоветовать?

 

И что следует выделять в каждую такую дллку - одна функция = 1 длл или сразу всю вычислительную часть забить в 1 длл?

Edited by NoobTrader
Link to post
Share on other sites
expforex2

естественно 1 dll на все функции. нет смысла вызывать большой список дллок.

 

не знаю кто в чем пишет ,я пишу на паскале, да и на с++ пишу, но честно сказать паскаль мне ближе.

 

Получилось, что тестируемые параметры постоянно изменялись, причем не плавно, а достаточно резко: оптимальные параметры для февраля на март уже не годились, за март - не годились на апрель и т.п.

 

Это говорит о том что ЕА не способна выдерживать поведения рынка, стало быть это и есть подбор параметров на прошедший месяц, но Вы не знаете будет ли такие параметры прибыльны в следующем месяце, как итог и мое мнение - такая ЕА опасна и не вызывает интерес.


Ищите программиста? могу помочь..

Link to post
Share on other sites
NoobTrader
Это говорит о том что ЕА не способна выдерживать поведения рынка, стало быть это и есть подбор параметров на прошедший месяц, но Вы не знаете будет ли такие параметры прибыльны в следующем месяце, как итог и мое мнение - такая ЕА опасна и не вызывает интерес.

 

Это вполне естественный вывод. Но ведь я на феврале оптимизировал прибыльность, а на самом деле (если посмотреть 2 годичные тесты) в феврале нужно, например, пережидать флэт и не гнаться за прибылью.

 

Т.е. параметры, которые усреднены на 2 года как раз и позволяют гипотетически пережидать неприемлемые условия рынка... разве не такой вывод следует из сравнения оптимизаций на месяце (которые не дают стабильных параметров) и, скажем, на годе (которая не дает просадки, но дает периоды флэта)?

Link to post
Share on other sites
NoobTrader
Это вполне естественный вывод. Но ведь я на феврале оптимизировал прибыльность, а на самом деле (если посмотреть 2 годичные тесты) в феврале нужно, например, пережидать флэт и не гнаться за прибылью.

 

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

 

Кроме того, ЕА за месяц всего-то и дает 4-6 сигналов. Тут сложно говорить о реальной оптимизации, просто не хватает статистической информации.

Link to post
Share on other sites
NoobTrader

Вот еще вопрос в тему появился:

 

Влияют ли на время оптимизации операции вывода/удаления с экрана графических объектов или вывода текста в окошке статуса (Print(), Label() ObjectCreate(), ObjectDelete() и т.п.)?

 

Следует ли все такие функции выловить и закомментить перед оптимизацией?

  • Thanks 1
Link to post
Share on other sites
extFX

1) Апгрейд железа.

2) Выбор правильного режима оптимизации.

3) Использование других языков программирования.

 

1) Апгрейд железа всегда положительно сказывается на производительности

а) Увеличение обоих параметров увеличивает производительность.

б) На сегодняшний день HT уже устаревшая технология, но отключать её не нужно

в) Увеличение обоих параметров увеличивает производительность.

 

3) Использование компилируемых в "нативный код" языков программирования всегда положительно сказывается на производительности. В идеале на MQL нужно обрабатывать только ввод/вывод данных и рисование, всё остальное во внешних многопоточных модулях.

Link to post
Share on other sites
Programmer
Вот еще вопрос в тему появился:

 

Влияют ли на время оптимизации операции вывода/удаления с экрана графических объектов или вывода текста в окошке статуса (Print(), Label() ObjectCreate(), ObjectDelete() и т.п.)?

 

Следует ли все такие функции выловить и закомментить перед оптимизацией?

 

Графические объекты не влияют на оптимизацию, т.к. в таком режиме они даже не создаются. Более того, если Ваш советник в своём анализе использует графические объекты, например STDEV CHANNEL, то советник будет оптимизирован неверно. Все графические объекты необходимо заменить соотв. им индикаторами. Нпример, STDEV CHANNEL INDICATOR.

 

Label() - аналогично.

 

А вот ф-ии Alert() и Print() продолжают работать и тормозят оптимизацию. Их надо закомментировать обязательно.

Link to post
Share on other sites
NoobTrader

Cпасибо большое всем за ответы!

 

Частично я решил свою проблему, оптимизировав код (у меня ЕА работает на 4х часовом графике, поэтому я убрал потиковый пересчет параметров графика, заменив на расчет раз в 4 часа). Время оптимизации стало гораздо более приемлемым.

 

Но все равно попытаюсь освоить написание dllк, чтобы теперь уже всю арифметику вынести в отдельный модуль.

 

Если можно, вот здесь уточнить:

 

Графические объекты не влияют на оптимизацию, т.к. в таком режиме они даже не создаются. Более того, если Ваш советник в своём анализе использует графические объекты, например STDEV CHANNEL, то советник будет оптимизирован неверно. Все графические объекты необходимо заменить соотв. им индикаторами. Нпример, STDEV CHANNEL INDICATOR.

 

Например, диагональные каналы я заменил на две линейные функции и рассматриваю в ЕА положение цены относительно границ каналов (=т.е. значения линейных функций от времени).

 

Никакой графики (функций типа CreateObject) ЕА не использует при анализе.

 

Правильно ли я понимаю, что в таком случае проблем с оптимизацией не должно быть, т.к. ЕА в любой момент будет видеть числовое значение соотв.линейной функции?

Link to post
Share on other sites
Programmer

Частично я решил свою проблему, оптимизировав код (у меня ЕА работает на 4х часовом графике, поэтому я убрал потиковый пересчет параметров графика, заменив на расчет раз в 4 часа). Время оптимизации стало гораздо более приемлемым.

 

Т.е. теперь Вы оптимизируете по ценам открытия?

 

Если можно, вот здесь уточнить:

 

Например, диагональные каналы я заменил на две линейные функции и рассматриваю в ЕА положение цены относительно границ каналов (=т.е. значения линейных функций от времени).

 

Никакой графики (функций типа CreateObject) ЕА не использует при анализе.

 

Правильно ли я понимаю, что в таком случае проблем с оптимизацией не должно быть, т.к. ЕА в любой момент будет видеть числовое значение соотв.линейной функции?

 

Конечно можно!

Да, Вы правильно понимаете. Нет ObjectCreate() - нет проблем.

Но я на всякий случай посоветую Вам внимательно посмотреть правильно ли рассчитывается Ваша линейная ф-я. Я в своё время над ней пыхтел дня два. У линии есть два тонких момента: она смещается при переключении ТФ, и Ваша формула должна аккуратно обрабатывать переход линии через выходные дни, иначе будет виртуальный обрыв.

Link to post
Share on other sites
NoobTrader
Т.е. теперь Вы оптимизируете по ценам открытия?

 

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

 

Я пока не понял, что (какое явление на рынке) могло бы реально стоять за этим сдвигом, но во всяком случае из за сдвига я строю функцию не по линии закрытия нулевого бара (и не по линии его открытия), а по линии закрытия, скажем 5го или 7го бара. Т.о. на разных вариантах эксперта канал как бы "запаздывает" на 8-20 часов.

 

А промежуток от нулевого бара до конца сдвига используется в ЕА для обнаружения "пробоев" в канале.

 

В этом есть некоторый смысл, т.к. если бы канал не запаздывал, то и его "пробоев" бы не было - и тогда при "пробое" канала ЕА бы думал, что можно торговать. Сейчас же я ему запрещаю это делать.

 

Но я на всякий случай посоветую Вам внимательно посмотреть правильно ли рассчитывается Ваша линейная ф-я. Я в своё время над ней пыхтел дня два. У линии есть два тонких момента: она смещается при переключении ТФ,

 

А вот таймфрейм у меня задан жестко... как и сам инструмент... т.е. советнику в общем не важно, что я делаю с графиком, насколько приближаю/удаляю - он всегда "видит" только заданный ему ТФ, и канал в общем-то существует только у него "в голове". Какие-то рисуночки на графике он только для меня оставляет, для того, чтобы я видел, что он считает уровнями...

 

и Ваша формула должна аккуратно обрабатывать переход линии через выходные дни, иначе будет виртуальный обрыв.
Вы видимо имеете ввиду "пробой" канала, если после выходных рынок рисуется с гэпом за границу канала? Тогда это еще не так страшно. С учетом сдвига графика ЕА и так видит "пробои" по нескольку раз в неделю... в общем, для того я и задался написанием фильтра с каналом, чтобы отсеивать автоматически такие периоды, когда рынок прорывает созданные ранее сильные уровни. Эта потребность в обнаружении пробоев от опыта ручной торговли еще появилась... Edited by NoobTrader
Link to post
Share on other sites
NoobTrader

вот такой еще вопрос, сформулирую его так, чтобы уложился в тему о ускорении вычислений...

 

Хочу встроить в ЕА автооптимизатор, (если конечно ручками найду в нем параметр, который "выгодно" оптимизировать на опережение). Не хочу при этом делать запуск второй версии метатрейдера, а хочу, чтобы ЕА сам (например, вечером в пятницу) эмулировал генерацию тиков на срок 3-4 месяца назад.

 

Мне кажется, что, раз ЕА работает на ТФ Н4, то мне достаточно взять для этой эмуляции историю по часовому графику - только по четыре цифры для каждой свечи: ОНLC. После этого ЕА по циклу сгенерирует 15-минутный график (как бы по 4 тика за час, тупо по точкам О-Н-Л-С), симулирует открытие/закрытие позиций, и генерацию прибыли, и прикинет, где он бы открывался и закрывался. Ну а потом, скажем, по генетическому алгоритму создал бы начальную популяцию и мутациями/скрещиванием, каждый раз прогоняя по циклу, оптимизировал бы сам себя.

 

Т.к. все упирается в объем вычислений мне интересно, прежде чем браться за собственно написание оптимизатора и ген.алгоритма - действительно ли можно для оптимизации ЕА, работающей по Н4 ограничиться ТФ Н1? Или все же надо восстанавливать весь график от минуток?

Link to post
Share on other sites
Programmer
Вы видимо имеете ввиду "пробой" канала, если после выходных рынок рисуется с гэпом за границу канала? Тогда это еще не так страшно. С учетом сдвига графика ЕА и так видит "пробои" по нескольку раз в неделю... в общем, для того я и задался написанием фильтра с каналом, чтобы отсеивать автоматически такие периоды, когда рынок прорывает созданные ранее сильные уровни. Эта потребность в обнаружении пробоев от опыта ручной торговли еще появилась...

 

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

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

 

post-50854-1404213798,3056_thumb.jpg

Link to post
Share on other sites
NoobTrader
... если Вы, допустим, построили некую нуклонную линию по двум точкам, находящимся внутри одной недели, и пытаетесь продолжить эту линию за пределы недели, то в некоторых случаях (в зависимости от логики построения) необходимо учесть потерянные дни в расчётных формулах. См. рис.

 

Интересно, пропущенные дни я, кстати, не учитываю... спасибо за идею, надо попробовать как-то проверить влияние потерянных дней...

 

Честно говоря, я не понимаю, по каким точкам построена верхняя толстая наклонная. Она вроде не касается цены на горизонте выделенной вами недели - а похожа просто на линию, параллельную тренду.

 

Т.е. почему она является сильным уровнем, я не вижу.. вот прикрепил скрин экрана Н4 с моим каналом - там как раз видно как на стыке недель ЕА нарисовала канал по трем точкам..

post-59174-1404213803,4034_thumb.jpg

Edited by NoobTrader
Link to post
Share on other sites
NoobTrader

И еще вопрос по теме, м.б. кто-то знает ответ: если система работает с одним ордером, и его Тикет-номер хранится в переменной Ticket, то как быстрее его закрывать:

 

if (OrderSelect==true);

OrderClose(OrderTicket(), бла-бла-бла

 

или:

 

if (OrderSelect==true);

OrderClose(Ticket, бла-бла-бла

 

интуитивно - второй способ быстрее. Но намного ли?

 

понятно, что в жизни разница во времени будет не заметна, но наверно заметна в оптимизации..

Link to post
Share on other sites
Programmer

Честно говоря, я не понимаю, по каким точкам построена верхняя толстая наклонная. Она вроде не касается цены на горизонте выделенной вами недели - а похожа просто на линию, параллельную тренду.

 

Т.е. почему она является сильным уровнем, я не вижу.. вот прикрепил скрин экрана Н4 с моим каналом - там как раз видно как на стыке недель ЕА нарисовала канал по трем точкам..

 

Линия построена наобум.

Неважно, как она проходит, - это просто пример.

Link to post
Share on other sites
Programmer
И еще вопрос по теме, м.б. кто-то знает ответ: если система работает с одним ордером, и его Тикет-номер хранится в переменной Ticket, то как быстрее его закрывать:

 

if (OrderSelect==true);

OrderClose(OrderTicket(), бла-бла-бла

 

или:

 

if (OrderSelect==true);

OrderClose(Ticket, бла-бла-бла

 

интуитивно - второй способ быстрее. Но намного ли?

 

понятно, что в жизни разница во времени будет не заметна, но наверно заметна в оптимизации..

 

2й способ занимает на одну операцию обращения к оперативной памяти меньше. Совр. процессоры работают на частотах >1Ггц, т.е. >1 000 000 000 операций в секунду. Даже если МТ4 во время оптимизации будет занимать 1% процессорного времени, он будет делать ~10 000 000 операций в секунду. Т.е. указанное расхождение в коде замедляет оптимизацию на 0,00001%. Даже если Ваша оптимизация будет длиться 1 год, то указанная разница в коде заставит Вас ждать всего на 5,256 минуты больше.

Link to post
Share on other sites
Programmer
вот такой еще вопрос, сформулирую его так, чтобы уложился в тему о ускорении вычислений...

 

Хочу встроить в ЕА автооптимизатор, (если конечно ручками найду в нем параметр, который "выгодно" оптимизировать на опережение). Не хочу при этом делать запуск второй версии метатрейдера, а хочу, чтобы ЕА сам (например, вечером в пятницу) эмулировал генерацию тиков на срок 3-4 месяца назад.

 

Мне кажется, что, раз ЕА работает на ТФ Н4, то мне достаточно взять для этой эмуляции историю по часовому графику - только по четыре цифры для каждой свечи: ОНLC. После этого ЕА по циклу сгенерирует 15-минутный график (как бы по 4 тика за час, тупо по точкам О-Н-Л-С), симулирует открытие/закрытие позиций, и генерацию прибыли, и прикинет, где он бы открывался и закрывался. Ну а потом, скажем, по генетическому алгоритму создал бы начальную популяцию и мутациями/скрещиванием, каждый раз прогоняя по циклу, оптимизировал бы сам себя.

 

Т.к. все упирается в объем вычислений мне интересно, прежде чем браться за собственно написание оптимизатора и ген.алгоритма - действительно ли можно для оптимизации ЕА, работающей по Н4 ограничиться ТФ Н1? Или все же надо восстанавливать весь график от минуток?

 

Весьма сложную задачу Вы себе поставили.

По поводу вашего вопроса. В некоторых случаях будет достаточно H1, в некоторых - надо до M1 спускаться. Всё зависит от того, как советник анализирует поток котировок - если потиково, то H1 никак не хватит.

Link to post
Share on other sites
MetaQuotes

3) Использование компилируемых в "нативный код" языков программирования всегда положительно сказывается на производительности. В идеале на MQL нужно обрабатывать только ввод/вывод данных и рисование, всё остальное во внешних многопоточных модулях.

 

 

MQL5 сначала компиляется в managed байткод, а при исполнении в терминале полностью переводится в нативный x86/x64 код с поддержкой SSE2 команд.

 

MQL5 гораздо быстрее MQL4 как раз за счет исполнения в нативном коде. С применением MQL5 фактически отпадает необходимость выносить тяжелые расчеты во внешние DLL. DLL чаще используется для интеграции.

 

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


С уважением, служба поддержки

MetaQuotes Software Corp.

Link to post
Share on other sites
  • 1 month later...
ReasonMan
А вот ф-ии Alert() и Print() продолжают работать и тормозят оптимизацию. Их надо закомментировать обязательно.

Уточните, плз, откуда такая информация? И действительно ли она верна?

 

На сайте http://articles.mql4.com/ru/80 написано:

Особенности работы тестера стратегий на истории

- Некоторые функции отрабатываются/пропускаются без вывода

Это Sleep(), Alert(), SendMail(), SpeechText(), PlaySound(), MessageBox(), WindowFind(), WindowHandle(), WindowIsVisible()

 

Особенности работы оптимизатора торговых стратегий

- В журнал логов ничего не выводится ( включая функцию Print() )

Это сделано ради ускорения тестов и экономии пространства на диске. Если выводить полные логи, то файлы журналов нередко занимают сотни мегабайт.

Link to post
Share on other sites
Hitronrav
Уточните, плз, откуда такая информация? И действительно ли она верна?

 

На сайте http://articles.mql4.com/ru/80 написано:

 

Можно верить, а можно проверить :crazy:

 

Только что прогнал оптимизацию советника — сначала понапихал в него Alert'ов и Print'ов, потом убрал.

Делал всего 1 проход, за 2010 год, так как ждать долго неохота.

Итог: без Alert-Print'ов примерно 18,4 секунды, с ними 19,7 секунды.

Как видите, эти функции замедляют оптимизацию на несколько процентов...

Link to post
Share on other sites
ReasonMan

Спасибо за тест, Hitronrav, наглядно. 7% - тоже разница, учту. :-)

Но всё же ещё "хотелось бы услышать начальника транспортного цеха". Послушаем что скажет Кирилл.

Link to post
Share on other sites
Programmer

Я придерживаюсь своей т. зр.: Alert() и Print() замедляют оптимизацию.

Поясню.

Когда происходит компиляция кода в рабочий файл *.ex4 компилятор выбрасывает все закомментированные строки. Поэтому, если Alert() и Print() закомментированы, то повлиять они никак на оптимизацию не могут.

Идём далее. Пусть Alert() и Print() не закомментированы. Действительно, при оптимизации в логи ничего не выводится, но за счёт чего это достигается? Ведь, эти ф-ии всё же присутствуют в исполняемом файле. Достигается вот за счёт чего: программа-оптимизатор, выполняя Ваш код, каждый раз, когда натыкается на ф-ю, которая должна быть проигнорирована, принимает решение об игнорировании оной. Это занимает процессорное время, соответственно, тормозит оптимизацию.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...