3 ms·
This is awesome. It was fun to see where my intuition was way off. Had no idea indexing/not-indexing a column would make a 25,000x difference (makes sense thoug
by jamestimmins 3y ago
This is awesome. It was fun to see where my intuition was way off. Had no idea indexing/not-indexing a column would make a 25,000x difference (makes sense though as logN on a 10-million row table is 13, which is a lot less than a linear scan).
Was also very surprised to see how slow Bcrypt is.
edit: Yes, BCrypt, is designed to be slow. I just had no idea how slow. I assumed it was 100-1000 times faster than it is/can be.
- TonyTrapp 3y ago> Was also very surprised to see how slow Bcrypt is. Though unlike all the other examples here, this one is actually intentional. If/when computers become considerably faster, the cost factor of typical bcrypt implementations will be raised so that it stays slow, to keep it difficult to throw brute-force attacks at it.
- jamestimmins 3y agoFor sure, that's an important piece. But when I hear "slow hashing" I assumed it meant 1k-10k times per second, not <10 times per second. That's practically human speed.
- pjscott 3y ago“Practically human speed” is exactly what they’re aiming for. It’s meant to be used in human-speed applications, and to be as slow as possible in those use-cases without causing perceptible lag.
- stavros 3y agoThe bcrypt example is the only one that's off the mark. "How fast is this function that we've explicitly designed to be arbitrarily slow?" Well, it depends, how slowly did you configure it to run? Basically the important argument to bcrypt is literally the amount of time you want it to take to run on your hardware (ie the number of rounds).
- hatthew 3y agoThis one threw me off as well. I didn't see any configuration so I just assumed that it was only 1 iteration by default. After being off by several orders of magnitude, I looked it up and apparently it defaults to 4096 iterations.