Assuming that the parsing into params doesn’t do deep copies of the string data, that’s exactly why I expected it would be cheaper.
However, I did a (also naive 
) benchmark here of creating atoms out of strings, then doing an atom comparison vs comparing strings … and it turns out that the overhad of creation of atoms from strings is still faster than string comparisons when the strings being converted to atoms are short (1 to 6 character). As the length of the string grows, it (understably) gets progressively worse and even at pretty small sizes (15-20 characters) it crosses over and the string comparisons are considerably cheaper.
Note to get anything reasonably measurable on my laptop, I had to do runs in batches of 1 000 000 iterations! That said, if there are deep copies of strings going on, then the string comparison path probably never caches up.
Still, this isn’t the primary reason for not using atoms in this case, but it is perhaps an interesting aside. Or .. maybe not. who knows
