That is also an option, but testing for a flag itself takes time (and adds a degree of complexity).

My preference for this sort of thing is to have an internal method (eg _setpixel) that gets called to do the real work once all sanity checks have been performed, and where appropriate to expose that in documentation with suitable warnings.

Quite often one method invokes other methods in the same class with parameters it has already checked for sanity, so the availability of such internal methods can also give a free speed boost even when external users do not invoke them directly.

True.

Looking at the setpixel method it should also be possible to write a variant that iterates over a list of values, e.g. [x1,y1,colour1, x2,y2,colour2, ...] or arrays of x, y and colour. Then the validity checks are called once per method invocation regardless of the number of colour assignments. That might be sufficient for the example in the OP.

OP here, thanks for the replies. By "global" I meant to somehow disable all the slow sanity checks in Imager.pm. Methods like setpixel and getpixel are likely to be called a lot inside loops. Disabling the call to _valid_image on each pixel seems pretty safe so far and is a big gain. Since _valid_image is called in almost every method in Imager.pm they can all be fixed on line 658:

sub _valid_image {
return 1;
[download]