There are a few things I consider when I try to improve performance of my code. 1) I really like the advice of "make it run, make it right, make it fast" [0].

There are a few things I consider when I try to improve performance of my code. 1) I really like the advice of "make it run, make it right, make it fast" [0]. First I build it, then I write a thorough test harness (or make multiple versions run at the same time and check their results at runtime), then I rewrite it. 2) I don't really like optimising to the core, like it's mentioned in the article, things like Cython and numba often add dependencies that don't port well and they may reduce legibility and maintainability (that's more about Cython than numba). What I find most useful, and this should be obvious, that algorithm/data structure changes often yield the biggest benefits. 3) The old rule that if you speed up code that only runs 1% of the time, you're not gaining that much, I try to keep that in mind. (There are exceptions, of course.) 4) Performance is not just runtime, it starts with coding it up in the first place. So start to finish, you're not always better off with a fast language. If it's a one-off, it can be more performant to use a slow language, if it's a tool that will run untouched, you might want to spend some time tinkering with it. Etc. All of this seems obvious in retrospect, but it took me a while to appreciate these principles. [0] https://www.facebook.com/notes/kent-beck/mastering-programming/1184427814923414 https://www.facebook.com/notes/kent-beck/mastering-programmi...