Увеличение производительности шаблонов.

[IgorSush]

Приветствую!
Есть варианты поиска элементов на странице:

1. стандартными кубиками
2. через Xpath
3. Regex'ом из DOM
4. ?

Какой из методов меньше всего использует CPU?

Вопрос возник, т.к. в шаблоне есть ожидание(цикл поиска) нескольких элементов, и выяснилось, что именно этот поиск больше всего жрет процессор, а нужно запустить больше потоков.
Памяти хватает, страничка совсем простенькая. Совсем без браузера тоже никак.
Делал тесты, все 3 мои варианта занимают одинаковое время. Не знаю как именно оценить прожорливость.

Благодарю заранее

 

[Oleg1987]

В цикле пауза стоит? Если нет, поставьте пару секунд - должно помочь

 

[Sz5]

Регулярки меньше всего кушают

 

[IgorSush]

В цикле пауза стоит? Если нет, поставьте пару секунд - должно помочь

Да, поставил 2 секунды.. И до начала цикла тоже 2, так что находит один из искомых элеменов почти всегда при первом прогоне цикла. Просто много потоков)

Регулярки меньше всего кушают

Странное дело: делал замеры, искал в цикле(int i = 0;i < 1000;i++) всеми 3мя способами, каждый из 3х вариантов мне выдает стабильно 45 секунд. Т.е. как ни странно время одинаковое.
А как оценить именно использование ЦП? На графике диспетчера задач ничего не заметно...

 

[amyboose]

Самый менее прожорливый способ - это поиск через IndexOf с опцией StringComparison.Ordinall, но количество кода автоматически возрастает в разы. Но таким образом ты только информацию найдешь, а сам элемент обычно быстрее всего искать через XPath

 

[IgorSush]

Блин, ну IndexOf

if (instance.ActiveTab.DomText.IndexOf(@"Account NOT FOUND!!!", StringComparison.Ordinal) == -1)
       throw new Exception();

в 1000 цикле занимает те же 45 секунд! Ну не может же быть, что поиск элемента четырьмя разными способами стабильно занимал 45 милисекунд
Может это ПМ ограничиает скорость обращения к instance.ActiveTab

Понятно, проснусь, тупо сделаю шаблоны для каждого варианта и посмотрим сколько потоков потянет ЗП пока не сдохнет

 

[amyboose]

Блин, ну IndexOf

if (instance.ActiveTab.DomText.IndexOf(@"Account NOT FOUND!!!", StringComparison.Ordinal) == -1)
       throw new Exception();

в 1000 цикле занимает те же 45 секунд! Ну не может же быть, что поиск элемента четырьмя разными способами стабильно занимал 45 милисекунд
Может это ПМ ограничиает скорость обращения к instance.ActiveTab

Понятно, проснусь, тупо сделаю шаблоны для каждого варианта и посмотрим сколько потоков потянет ЗП пока не сдохнет

Может, так как в ПМ используется WCF + загружаются в домен библиотеки, а обмен ведется через Pipe, таким образом почти все время у тебя может занять отправка инструкций через этот протокол. Пробуй все циклы проводить в одном куске C# кода

 

[Lord_Alfred]

Понятно, проснусь, тупо сделаю шаблоны для каждого варианта и посмотрим сколько потоков потянет ЗП пока не сдохнет

Любопытно узнать результаты, запили и выложи потом обязательно)

 

[IgorSush]

Пока я гоняю у себя на серваке, можете тоже потестить, шаблоны прилагаю
По поиску варианты: Xpath, IndexOf, DomText regexp, Domtext.contains, FindbyAttribute, Стандартные кубики
По SetValue и GetValue: Xpath, ByAttribute, Стандартные кубики


Шаблон имеет смысл только на версии Pro
В настройках проекта выбираете вариант замера и паузу в цикле(если нужно).
Ставьте в настройках ЗП максимальные 5000 потоков(может придется перезагрузить ЗП), Шаблон запускайте и постепенно увеличивайте потоки.
Выскочит окошко виндовсФормс со статами. STOP работает не мгновенно, Close обнуляет счетчики.
Ну и диспетчер задач с загрузкой CPU

Можете пинать код сколько хотите, я не обижусь, т.к. нуб)
А еще лучше допилите кто шарит

 

[IgorSush]

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

Итак,
Поиск элемента на странице:
-Xpath, IndexOf, FindbyAttribute выдают приблизительно одинаковые 2000/с, CPU грузится на 65%
-DomText regexp, Domtext.contains - 1600/сек, CPU 50%(Думаю дело в том, что теряется время на присвоение переменной текста всего DOM)
-Кубики. Здесь странно, всего 30/сек, 10% CPU(подняв потоки до 150 вышел на 80/s и 90% СPU.) Тут мысль такая, что сам экшн(фокус, клик) идет с каким-то внутренним таймлагом.

GetValue и SetValue показали одинаковые результаты:
-Xpath - 1150/сек, 55% CPU
-byAttribute - 3800/сек, 65% CPU
-Кубики - 2300/сек, 65% CPU


Итого мои выводы...
-Кубики. Искать ими не надо, а вот устанавливать значения вполне можно.
-DomText regexp не так уж и хорош...
-Xpath для поиска элементов не жрет и не тормозит, как я думал ранее, а вот для get|set оказался худшим из вариантов.
-get|set лучше всего делать через instance.ActiveTab.FindElementByAttribute(...).GetValue...
-Не туда копаю, мои шаблоны жрут CPU в чем-то другом.

В аттаче новая версия шаблона, если кому интересна. Там допилил кое что по ходу.

 

[IgorSush]

Все никак мне не дает покоя эта тема.
производительность цикла БЕЗ самого поиска(просто присваивал значение переменной):
итог 7600000/сек, 75% CPU. Т.е. потолок высоко, а замеры достаточно достоверны.

И все же я откопал что жрет проц! Эврика! Допилил возможность выбора уровня эмуляции при SetValue.
Итого, при прочих равных:
Уровень "None" - 1800/ceк, 70% CPU
Уровень "Middle" - 750/ceк, 98% CPU
Уровень "Full" - 330/ceк, 85% CPU

Вывод:
-Жрет не поиск, а эмуляция при SetValue!
Использовать эмуляцию только по необходимости! Я это и так знал, но не думал, что это так существенно, в основном оставлял все в дефолтном "Middle"
Вот и сказочке конец