Performance guide and a design pattern, learning path

I would say that you can start by reading the hexdocs and have a general knowledge of what is possible to do with it.

Then depending of what you want to do with the application, might have several possibilities of optimizations / performance. I would recommend also if you are doing something with HTML/JavaScript to take a look into LiveView.

Here are some topics about specific things, but not necessary related to Phoenix.

https://medium.com/@ron.arts/optimizing-elixir-phoenix-performance-a50f7c92b9e4

OK, thank you for your answer and guide on this matter.

What i looking for when I asked this question is this:

Minimal calls to the database

Fast performance 2=2 also (2-1)*2 is also 2 but takes more work so I am looking to understand how I should structure my apps and what functions to use to gain performance. A example would be that Enum.map is slower then a recursive head tail and acc.

How to cache correctly and only what is needed.

So if anybody else would like to add there personal opinions or experiences I would be grateful.

Thanks in advance.

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.

The link towards the GitHub repo is very useful to me.

Also you other thought on this matter are very helpful for me to understand better my requirements and possibilities.

Thanks for writing you idea and opinions

Also is there something similar to POODR from ruby on rails in elixir phoenix?

I am asking because i know alot of memebrs of this forum come form ruby on rails so maybe some of you know of good book or resource similar to the one above.

I’m not familiar with Ruby neither POODR, but in terms of books I can recommend Elixir in Action by @sasajuric.

Also have a general overview how GenServers, Ets and NIFs work. Maybe GenServers and Ets will more useful for you to know than NIFs, but knowing that they exists might be handy.

Thanks for the recommendations.

Also found this for anyone that wants to go this path of learning design patterns:

There are a couple of threads on this that really caught my eye.

I found this video while looking at functional design patterns, I like it a lot…