Checkout Elixir function decorators — decorator v1.4.0 which implements a module attribute based decorator pattern.
The main code for defining decorators is here: decorator/lib/decorator/decorate.ex at master · arjan/decorator · GitHub
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
dimitarvp
I wonder if I am missing something here. Whatever solution you end up with, this:
…should be replaced with this:
{micros_elapsed, return_value} = :timer.tc(fn -> apply(fun, args) end)
And I see that @garrison and @billylanchantin already beat me to it.
0
BartOtten
Mandatory link in every Macro topic: The Erlangelist - Understanding macros, part 1
While searching for it I landed on part 6 just to learn me something about AST context which I solved in a pull request less elegantly. “Just in time” they call it 
Read all 6 blog posts and the answer will be in one of them. Guaranteed.
0
BartOtten
Now the other mandatory thing: what do you want to accomplish?
You started by stating what you want the code to be able to, but what do you want with that data? Maybe we can find another solution getting you the same data/analysis.
0
MadsBoydMadsen
Thanks a lot for all your lovely contributions.
I’ll look through it all when I have a bit of time.
My aim @BartOtten is to work out why a particular action, that our users are doing, is timing out. It is critical to solve this problem, as it prevents our users from doing much meaningful work in our system.
It only happens in production. I’ve done significant investigations already (such as analysing the SQL-executions in an attempt to spot poor performance - which has yielded very little), and decided my next step should be to time the call-sequence in the application to narrow down where the problem is occuring.
My colleague already has a solution to time functions, but it struck me as useful only if you want to time little parts of the application. In my use-case, I really need to instrument the entire call-sequence, as I literally have no idea where the problem is coming from, and as it is expensive to repeatedly hotfix the production system.
Maybe there are tools out there which does this at a snap of my fingers - I don’t know.
The functional decomposition of the application is deep rather than flat (please don’t comment on that 
), so I thought it would be helpful with an instrumentation mechanism that is really easy to apply. It would benefit the PR-review for the hotfix(es) to be able to easily see, that functionality has not been altered by applying timing code. Hence the idea of using a macro that substitutes def with def_timed - really easy to see in the PRs
Are you with me ?
0
MadsBoydMadsen
BartOtten
I see your point. Trying to come up with less invasive solutions to find the issue.
- Have you tried to connect erlang Observer to the production machine? It gathers statistics about your runtime (memory usage, function reductions etc)
In a BEAM application, you can potentially have millions of processes running at the same time. In order to ensure that each process gets (roughly) equal share of the available CPU(s), the VM counts reductions. One reduction is essentially equivalent to one function call.
- How about erlang tracer or Tracer? Tracing is very powerful (and overlooked) in the BEAM! https://medium.com/hackernoon/a-guide-to-tracing-in-elixir-53b1afb996de
1
MadsBoydMadsen
kevinschweikert
Going in that direction maybe you can figure out the issue in dev with tools like The eflambe application which produces a flamegraph which you can inspect
1
BartOtten
Nice once. Although issues caused by n+1, long database (row) locks and memory limits are mostly non existent in dev environments. Every non-indexed table is working in dev environment
@MadsBoydMadsen If the problem remains and you are able to spin up a test environment, I know a reliable company which can help stress / durability test the app by carefully drafted scenarios.
why a particular action, that our users are doing, is timing out.
Can you tell use the particular action? I like black box riddles
Tip for those with no Product Owner or higher Management: have a CI pipeline which tests performance with a large (generated) dataset every night after changes to main branch (or even PR branch). Store the result and auto compare, raising when change is above a threshold. Once found a “add row element” caused the whole DOM tree rendering to come to an halt as in production it caused a lot of new DOM.
1