MD5 is a very fast hash and its output is short and easy to store. Should I use it for my non-security-sensitive application?
I don't think so, but I can't seem to convince anyone else that this is true.
When I need to show to others that they are wrong and it is their word against mine, I look to the words of industry recognized experts and then challenge them to find an industry recognized expert that supports their belief.
Wikipedia even has a nice article on MD5 security.
That said, you specify in your question that this is potentially for a "non-security-sensitive" application. What do you mean by that? Your comment seems to suggest that you are signing hashes of files. That to me seems security sensitive.
The only threats against MD5 are security, afaik it's mostly about its collision resistance (and some specific cases of preimage).
If you rite that app is "non-security-sensitive", maybe you should not care about those threats and gain from speed?
For some applications collisions are acceptable when happen very rarely - let's take hash tables as example.
If you app has similar requirements as Hash table datastructure, go and check out if there is even better choice than md5! (for speed, parallelism or other reason)
If I was developing a new application and could use any hash function, and my application is even a little tiny bit security sensitive, my default is (soon) SHA-3.
Last year, my default hash function for anything even a little tiny bit security sensitive was SHA-256. It's about half as fast as MD5.
MD5 and SHA-1 are adequate for some applications, so there's no real rush to update all the software that currently uses it for those applications. But I would use the above alternatives instead for any new application, because:
US-CERT says MD5 "should be considered cryptographically broken and unsuitable for further use." NIST says "Federal agencies should stop using SHA-1 for...applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010"
If I need a hash to use as a checksum detect accidental (i.e., not malicious) bit errors, and it needed to be faster than SHA-256, I would probably by default use a CRC-32 if there was a library implementation handy and I had plenty of program space. If I needed to implement some kind of checksum myself -- or if it needed to use very little program space -- I would by default write a Fletcher-32 checksum implementation.