SHA-256 Partial Collision of initial 36 bits and more
Actually, this sort of programming question is more suited for stackexchange.

However, to answer your question, there are two obvious approaches to speed up a collision search:


Use a Hash table; that is, instead of keeping everything on one big list, divide them onto (say) 1024 different lists (in such a way that you know that items on two different lists aren't "matches").  And, given that you know that the SHA256 is already wonderfully distributed, you can (for example) select the hash table entry that a specific hash is placed on by using the first 10 bits of the SHA256 hash value; that way, you'll never have to explicitly compare two hashes that differ in the first 10 bits.  That reduces the number of comparisons you'll need to do by 99.9%.  Of course, you'll adjust the size of the hash table (that is, how many entries it contains) according to the resources you have.
Use a sort algorithm; that is, use a good algorithm to sort the hashes into ascending order; that way, any 'close' matches will be adjacent, and so that's the only comparisons you'll need to make.  A good sorting algorithm on $N$ elements can be done in $O(N \log N)$ time, hence this is much faster than individually comparing each element.


I don't know which would be better in your situation; however it ought to give you something to think about.