Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We recently reduced our build times by 5-10% or so by changing the default bcrypt iteration count (for tests). It also felt silly once we found it.


Thanks so much for this tip! I just made this change and some of my tests are now much faster. Here's the result for one of the affected tests (averaged across 5 runs):

Before: 1.39 seconds

After: 0.62 seconds

I have this default line in config/initializers/devise.rb:

    config.stretches = Rails.env.test? ? 1 : 11
So hashing user passwords was already very fast. But I'm also manually calling BCrypt in some other places, so these calls are now much faster as well.


You should consider doing the same thing in production.

It's a trope at this point how the modern slow hashing algorithms are utterly misconfigured. Stopped counting how many times I've seen it.

Take a whole second to compute a hash on the production machine because "hashing is supposed to be slow", noting the production server is a low frequency Xeon that has many core but they're half as slow as your development with a 4GHz i7-9999.

Hashing is supposed to take milliseconds, not seconds. If it's taking longer than 100 ms you need to make it faster.

edit: found the problem, this bad stackoverflow answer that's been spreading bad recommendations for years https://security.stackexchange.com/questions/17207/recommend...


One thing to keep in mind is that this obviously changes the timing of your software with respect to production behaviour, which may or may not matter depending on what you are testing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: