← Back to team overview

sikuli-driver team mailing list archive

Re: [Question #197363]: Stress test with sikuli

 

Question #197363 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/197363

RaiMan proposed the following answer:
You talked about 500 client app instances running simultaneously.

Since Sikuli can only "see" what is currently visible on the screen, the area to show up for the client app windows is somehow restricted.
Usage of multiple monitors is possible.

For Sikuli to act (mouse, keyboard) on the client app, its window must be the frontmost.
Using switchApp() to do this, needs the window titles to be different for each client app (on Windows).

Since it is possible then to restrict the search area to this frontmost
window, only this interface will be "seen" (region of interest) by
Sikuli's find operations.

Generally I doubt, that it will be possible to run that many scripts in
parallel, even with some tweaking of the respective settings. So every
chance must be taken to restrict the search areas to the smallest
possible regions.

The image search is number cruching of arrays of bytes, which tends to
use up to 100 % cpu (if available) during the search. Example: If you
succeed in reducing the average search time to a value near 0.01
seconds, and each action block on a client app needs 5 searches, then
you might be able to act on about 5 app windows - if everything is
optimized.

Always have in mind: the fastest search is the one, that does not happen
- because you have e.g. calculated the next click point based on
something that already was found before or even with respect to the
window bounds - there are many options to avoid searches (e.g keyboard
shortcuts, tabbing through GUI fields, ...). People who start using
Sikuli tend to search too often.

-- 
You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.