You're welcome. The usual behavior for compilers is to generate slow code about as quickly as possible, maybe also with the best debuggability, and do things like add `-O`/`-O2` to get faster code generated more slowly. I don't think Nim should vary from that. I am not entirely sure how much speed-up comes from `-d:release`/`-d:danger` and just using the optimizing modes of gcc.
If people are coming from Python they are going to have to learn about compilation options sooner rather than later. Someone, like in this case, who seemingly thought to switch to an iterator but not to try higher compiler optimizations..Well, I don't know how to prevent that. Their mind is _almost_ in the right place. We can just wait until they respond to the did-you-do-d:danger as a first question before worrying, though. I'm only about 90% sure that's even what happened in this case since we haven't heard back from @markebbert. This `split` question also has come up a lot, eg.: [https://forum.nim-lang.org/t/1580](https://forum.nim-lang.org/t/1580) [https://forum.nim-lang.org/t/2282](https://forum.nim-lang.org/t/2282) [https://forum.nim-lang.org/t/3557](https://forum.nim-lang.org/t/3557) It may not always/often be the best approach but, it is an operation provided by literally virtually every programming environment. Even ANSI C has `strtok`. So, for good or ill, it's often a "first comparision". So, I think we probably should have re-usable `var seq[]` accepting overloads in the stdlib as well as the iterator in case whatever sample code needs random access to post-split members.
