sikuli-driver team mailing list archive

[RaiMan <question204641@xxxxxxxxxxxxxxxxxxxxx>]

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

    Status: Open => Answered

RaiMan proposed the following answer:
Yes, the internally used resources are definitely freed (besides the
fact, that every region stores the last captured screen image - which
might get a (little) problem when using many large regions (e.g. a
screen image of a screen 1920x1200 takes nearly 10MB storage).

So in your case, the problem are the intermediate copies/transformations
of large images (the int[] are always captured images of the respective
search area created with every find operation) in preparation of the
native image match.

So depending on how many of these operations are in parallel, there
might well be situations, where the sum of last_images stored with
regions/screens and intermediate storage needs might get more than 256MB

So if you use regions to minimize the search area (I hope you do !
because this generally boosts performance and robustness), then it might
be worth a try, to set at least the larger ones to null after they are
not needed any longer.

Same goes for the screen objects (when used as search regions e.g.
scr.click(image) ), that might be used in every parallel test workflow.

As far as I read, running the gc in between normally does not make any
sense (at least with the actual versions of JRE). If memory is
available, the gc runs when needed and the max values are consumed
periodically. So with some profiling tool, it is necessary, to watch the
minimum level, where the memory consumption should come down
periodically. if this rises over time without any reason looked from
your code, then it might be a memory leak in the imported stuff.

You should look into the specific options for the heap space, that are
possible to define as java parameters and allow some fine tuning of heap
space usage.

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