Minor optimization suggestion - compareHashes

[Linguica]

I was doing some webgrind profiling and saw that when loading a topic page, the second most time of any function was in a hash comparison function:

From a quick glance it seems like the app is reusing a hash comparison function from the login password checker to check other various data. The issue is that the hash comparison function is purposely constant-time. This makes sense for checking a password hash since it lessens the chance of a side channel attack from a hacker spamming lots of password checks and carefully timing how long it takes to complete. But it's somewhat less useful for checking hashes of other, non-sensitive data.

I experimented with creating a new compareHashesFast() that just does a simple string equality check and returns true or false based on that, and replaced the calls in the __get and__isset methods just to test it out, and it seems to work fine. Unless I am missing some truly distressing problem with this, it seems like it will give a small speed bump for basically free.

[RevengeFNF]

Good finding.

Lets bring @Charles here as they are doing a performance review of the suite

[TSP]

The compareHashes-method is deliberately slow. 

Quote

While I'm unaware of any cases of this actually happening, we want to make sure that our products are as secure as they can be. For this reason, in 4.0, we're migrating to Blowfish. Blowfish is a more cryptographically secure technique for generating hashes that is deliberately slow, meaning that even if your database were ever compromised, the passwords will still be secure.

It sounds like you're trying to use the method for something that's not intended? Why/how do you compare non-sensitive data with the compareHashes-method?