OK, I switched it to use OpenSSL for the key derivation, and it is much faster.  Did a 99,171 word dictionary file in 53 seconds: 1,871 per second (3 GHz processor.)  The downside could be that it doesn't work on your system because it's not pure Python.  I think it's supposed to work on Windows if you have OpenSSL DLL's, and maybe on Mac OS too.  It's here: https://gist.github.com/scintill/5829284/54bcc0a9a44809c3fb4b53259239316520bbfe17 .  The OpenSSL wrapper is from here: https://github.com/joric/brutus/blob/master/ecdsa_ssl.py .

Make sure you are using the right compression flag (which translates into the DER-encoding of the pubkey: starts with 04 hex byte if uncompressed, 02 or 03 if compressed.)  Whether your address is compressed will depend on what tool and settings you used to generate it.  If it has been spent from before, then you can look in the blockchain to be sure of whether it is compressed or not.  Otherwise, I don't think you can tell from just the address.  You can tell from the private key, which starts with 5 if uncompressed, K or L if compressed.

The Python way can be parallelized pretty easily by splitting the input file into, say, 4 files, and running 4 instances of the script at a time.

If you want to try OpenCL, from what little I know, I think it would be best to do the SHA256 in batches (so the inputs are the same smallish uniform size they are now), then give all the hashes to the OpenCL kernel, and have each kernel derive the hash160 and see if it equals the target address, and run those in parallel.  I guess the SHA256 becomes a bottleneck, so maybe it would be better to try to do that in the OpenCL kernel, but as far as memory management it might be harder to adjust the vanitygen design for string inputs.

Also, I think the base58-encode is not quite right in the Python. It should pad with "1" for each leading zero in the public key hash.  If your target address doesn't start with "11..." I don't think it will matter though.

Ouch, glad you got it sorted.  It could be leaking memory.  I do see some free() calls, so the author put some consideration into it, but they may have missed others.  Generating tens of thousands of keys in one run isn't a usecase they probably considered.  I don't know much about ctypes to know for sure.  Good luck!