jeffdeville
How to determine why elixir compilation w/ a macro is taking 202seconds
I’ve got a macro that wasn’t impacting my project compilation speed much. I added a small feature to it, and now it’s ~50x slower. But at least to look at it, it certainly doesn’t appear as if 50x more work is being done.
Are there any tools I can use to determine why this is the case? After the AST is generated (this part is fast), I’m not sure where things ‘go’, or what tools I might have to identify the source of my slowdown.
Marked As Solved
jeffdeville
Thanks Jose. I fixed the problem and I think I’ve got something interesting to report.
First, I made the changes you suggested. Boiled each method down to 1 line in another module. The compilation time was still 108 seconds.
The fix was to inspect all of the values I was writing into my @docs that were not strings. (atoms, and ints)
I changed my @docs from:
@doc """
#{unquote(desc)}
* Field Type: #{unquote(type)}
* Units: #{unquote(units)}
* Addr: #{unquote(addr)}
* Num Bytes: #{unquote(num_bytes)}
"""
to
@doc """
#{unquote(desc)}
* Field Type: #{unquote(inspect type)}
* Units: #{unquote(inspect units)}
* Addr: #{unquote(inspect addr)}
* Num Bytes: #{unquote(inspect num_bytes)}
"""
and my compilation times sped up 43x
Also Liked
josevalim
If this is being called a lot of times, then yes, the amount of code you generate will have a direct impact on compilation times. If you can post a snippet, we can help reduce the compilation time, but this may very well be a hint to find another approach that generating many many functions.
In any case, it is also worth mentioning that Elixir v1.5 speeds up how function definitions for large modules, so maybe try out Elixir master and see if that improves the situation.
josevalim
That’s very interesting. Thanks for reporting back. Which Erlang version were you using?
Can you also post what those strings would look like before and after your changes? I am wondering if inspecting is limiting something that would otherwise be very large or if it is forcing the string to be rendered as a binary which would affect the rest of compilation.
Compilation of large literal binaries/strings have been generally improved in OTP 20 though: Move expansion of strings in binaries to v3_core by josevalim · Pull Request #1131 · erlang/otp · GitHub
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








