Most heavy duty operations are done using compiled native executables, IPP is the organisation glue that holds everything together.
Excellent performance is one of the main goals of IPP. To achieve this, the project has undertaken careful consideration regarding the choice of compiled/runtime languages and third-party libraries.
This is why more computationally intensive operations are done using bundled compiled binaries. For example, image resize operations are done using libvips, an amazingly efficient and fast image manipulation library.
At the moment, pipes use pre-compiled binaries for the three major operating systems (Windows, macOS and Linux).
In the future, pipes may bundle a universal WebAssembly module that would work cross-platform, and even in the browser. The technology is not fully matured, however, and would require a certain amount of work to compile C++/Go source into a WebAssembly target.
The biggest factor that determines performance is the choice of pipes in your pipeline. One of IPP's directives is speed, by using native binaries from performant image libraries. Speed is therefore not determined by the compiled language used, but rather by the nature of the pipe.
Resizing images is relatively cheap, however dedicated compression libraries (such as those provided
@ipp/compress) whilst providing superior image quality must sacrifice in speed.
Another example of an computationally intensive task is generating SVG placeholders using the
@ipp/primitive pipe. The algorithm generates an arbitrary (based on the given options) number of
test images in order to determine the best fit for the original image.
If performance is a major concern for your implementation, it may be best to stick to "cheap" pipes such as resizing and converting.
|resize||🟢||C||Resizes images using the libvips library|
|convert||🟢||C||Converts image formats using the libvips library|
|compress||🟠||C, C++||Compresses images using various implementations|
|primitive||🔴||Go||Generates primitive SVG placeholders|