In this post I explain why you shouldn’t use Ioncube encoded Magento modules.
Ioncube is an encoding system for PHP files. Ioncube-encoded files aren’t readable (by humans) so software companies use it to protect their intellectual property.
Many commercial Magento modules are encoded by Ioncube. Performance wise, this is not a good thing. Why? Ioncube integrates with PHP and attaches itself to the include/require functions. Every time a PHP file is required (regardless of whether it’s Ioncube-encoded), it is opened first by PHP itself and then again by Ioncube1. The decoder is closed source so humanity will probably never find out why, but the result is a performance penalty.
The magnitude of this performance penalty obviously depends on the amount of files opened. And with Magento, the amount of opened files per pageview is humongous. Without compiler mode, Magento opens 465 files for a productpage of the 1.5.1 sample shop, so Ioncube will duplicate these to roughly 900 opens2.
A good thing: if you are NOT using an opcode cache (such as APC) you probably will not notice the delay, because sequential open() calls are likely cached by your filesystem cache. Ie, your shop will be equally slow with or without Ioncube. However if you are using APC (because you wanted to eliminate disk i/o), you are in for an unpleasant surprise, because the expensive disk i/o has returned.
Therefore I would recommend AGAINST using Ioncube modules on popular shops that are already using opcode cachers such as APC. If you absolutely need the module, ask the developer for a non-encoded version. In any case, do a full load benchmark before loading Ioncube on your production servers.
 Proof: without loading Ioncube, PHP opens files with the O_LARGEFILE flag. With Ioncube loaded, every open() call is duplicated but the second one is without the O_LARGEFILE flag.
 Actually slightly less than 2x because not all open() calls correspond to require/include PHP functions, for example when a config.xml is loaded.