I agree to an extent. But some of the optimizations petrich has done would blow up the size of the file, as well, if not done with create_function and the like.

Like one of the things he's doing (and correct me if I'm wrong petrich) that's contributing to the speed is this:

```php
extract($self->keys[CRYPT_DES_ENCRYPT_1DIM],  EXTR_PREFIX_ALL, "k");
...
$b1 = (($r >>  3) & 0x1FFFFFFF)  ^ ($r << 29) ^ $k_'.(++$ki).';
```

ie. he's taking advantage of the fact that I guess it's faster to lookup a variable for PHP than it is for PHP to lookup the index of an array.

That could be done, one by one, for every element in the key, in without using create_function() but it'd take a lot more space. And although I think the create_function() technique does impair readability and maintainability somewhat I think it'd impair readability even more to not use create_function(). ie. I'd rather read a 10k chunk of code than a 100k chunk of code or whatever.

The difference is even more pronounced in Crypt_Rijndael. Prior to petrich's optimizations Crypt_AES was a partially loop unrolled version of Crypt_Rijndael. That partial loop unrolling led to an almost 50% speedup. petrich's changes loop unroll it even more than before and for every possible key / block length combo Crypt_Rijndael uses.

Optimizations that impair readability are not without precedent. See, for example, crypt_random:

https://github.com/phpseclib/phpseclib/blob/master/phpseclib/Crypt/Random.php#L59

`PHP_OS & "\xDF\xDF\xDF"` is hackish but it's a ton faster than `strtoupper(substr(PHP_OS, 0, 3))`. And in that particular case (and in the case of the symmetric ciphers) I feel it's at least somewhat justifiable since those functions could potentially be called 100's or thousands of times, one call right after the other.