I’m not sure there is very much value in generic advice to give for your questions. There’s GitHub - devonestes/fast-elixir: 💨 Writing Fast Elixir -- Collect Common Elixir idioms. · GitHub, which is useful to have seen, but I don’t think it’s a good guideline for general programming. It promotes testing performance changes I guess, which is a good thing.
In general I’d like to point to the often quoted Joe Armstrong:
Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!
So unless you really need to – use Enum.map over a custom, optimised recursive function. It’ll be more expressive, easier to read and maintain.
Sticking to the quoted advice has not only the benefit of the generic meaning, but also that once you hit the “make it fast” part you’ll already know your problem quite well. So you can go around and ask people about “how to make X faster”, which is usually way more productive.
This is even less answerable in a generic way. Maybe cache as few things as possible and as much as needed? What to cache highly depends on what data you handle (how big, shape, …), from where you retrieve it and how fresh it needs to be for your users to be useful. Big, hardly changing data, which is fine to get stale → great for caching; Constantly changing data → not so great. Retrieval of some piece of data is too slow? Check how long the data can be stale.
I hope you see that I’m hardly talking about programming at this point. This is about constraints to the business/users/sources of the service your app provides. It takes talking to those to find out what you can or cannot do.
Edit:
I guess one generic thing to know would be how different datatypes work and how they interact with Algorithmic complexity. It’ll give you topics/vocabulary to talk about with other people. Things like: Appending is expensive for linked lists.
