Which image size is better?

Sikuli in the moment works strictly pixel by pixel. so resolution does not matter.

when you say something like
find("path-to-an-image-as-png-file")
a screenshot of the whole screen is taken and the pixel pattern of the "image-as-png-file" is searched for in this screenshot (this is the region of interest (ROI)).

the overall experience with speed is, that the size of the images (as number of pixels) to be searched for does not matter very much.

but setting the ROI to a smaller region than the whole screen, in most cases boosts performance.
So if you have an idea, where your image is on the screen (e.g. inside of an application window), there are some functions that restrict the search area.

to get an idea you should look at the Complete Guide ... Region.

Here's what I found with some testing...

When you make a Pattern it doesn't load the image, it grabs the image from the file everytime you run find()

Changing similar() to 1 or using exact() doesn't make it faster. In fact when I do a screenshot of something and use exact() it fails to find anything.

Using cap=capture(...) and then cap.find() will not search the picture in the image you've just captured. It'll regrab the image from the screen again.

Most importantly, not finding something kills a lot of time, there's something wrong here cause not finding something takes 3.5secs on my computer whether I have a very small ROI size or the whole screen. But it only takes a fraction of sec if I find something.

@ niknah
some comments:

--- I confirm, that even in cases where the match reports a similarity of 1.0, trying to find the image with exact() fails. I found, that in these cases using 0.99 always works (a bug?).

--- Internally with each find operation all matches, that have the minimum similarity or better are collected, but only the best match is returned. So increasing the minimum similarity decreases the number of matches collected. But I found, that this has no significant effect on speed (if found, it returns after about 0.3 seconds (in my environments)).

--- Using cap=capture(...) and then cap.find() ... is not valid Sikuli script!
this construct does not mean, that something is searched in the image file referenced by cap (stored in temp).
Since cap is a string containing the file name and the parameter of find() is also a string (file name of the stored image file in .sikuli), this construct does not give an error, because class string knows the method find(). the result should always be -1, since the naming patterns of interactive captures and static captures are different.

--- AutoWaitTimeout
the find operation tries again, if a find failes, until the timeout is reached. this is 3 seconds by default. So its clear, that every FindFailed costs about 3 seconds. This is, to allow workflows, that act on visual objects and have some spare time to give the app a chance to change the screen content, before the next find operation takes place.
If you know what you are doing, you can use setAutoWaitTimeout() to a lower value or use wait() and exists(), to implement your own timing.
If I know, something should be on the screen already, I always use exists(some-image, 0), which stops after one try and returns False if not found.

so I prefer if it makes sense:
if not click(exists(image-of-button, 0)): raise FindFailed("something wrong") # FindFailed after first try

instead of:
click(image-of-button)
which in case of FindFailed waits 3 seconds to come up with a FindFailed error.

Thanks very much!
The AutoWaitTimeout was what I was missing.

And I had a bad habit of putting except: everywhere when I should have used Except FindFailed: instead which hide some of my errors.