I hear you, only loading what's needed is good, but in this case it'll make `parse` less predictable. On the one hand regarding performance, because you never know how long the filesystem might take to give you what you asked for. The file might be in the kernel's fs cache, or in the device's cache, or even on a spinning disk that's in standby. Without the `require` call, the method's runtime is dependent only on input, but with `require`, you can only guess.

This blocking IO operation is especially problematic when combined with a threaded webserver like Puma or Reel, since probably all of the interpreters have a global lock around `require`. It also used to be not threadsafe at all in MRI, but I don't know if that's still an issue.

On the other hand, it introduces one more possible way for `parse` to fail. `strscan` is currently part of the stdlib, so you can be pretty confident that it's there, but the discussion about splitting the stdlib into gems is still open, from what I remember. If you load the dependencies right at boot time, you can safely assume that, once the process runs, it will continue to run. Recovering from a missing dependency is hardly possible (from a code pov), so it's useful to give feedback as early as possible, and bail out.