eugene.kobil
Hi everyone,
I worked on some issue on my project that was related to the performance slowdown brought by Protocol impl_for/1 active usage (on Elixir v.1.10.4).
I found out that on newer elixir versions (starting from v.1.11) this issue has gone.
According to my measurements the cost of impl_for call reduced from ~70ms on v1.10.4 to < 1ms on v1.11.
I tried to find some change logs that mention this improvement or at least some specific commit in v.1.10.4..v1.11 diff but did not succeed with it.
Does anyone knows what exactly could improve impl_for performance?
Thanks
Trending in Questions
I’m working on a project that simulates the bumbl example in the programming phoenix book. It acts almost like an email client. We have a...
New
Hello,
I know there is an approach for handling lists that allows for optimized traversal, but I can’t recall the specific method (somet...
New
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
So my question is quite simple and i have found no conclusive answer on forum, google or AI.
Should we use :erlang.float for Integer to ...
New
Documentation
While reading the Scoped Routes section, I noticed that the documentation currently refers to a problem without explainin...
New
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
If a change or preparation module uses Ash.Changeset.get_argument/2 or Ash.Query.get_argument/2 (or any of the other get_argument functio...
New
Other Trending Topics
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hi there! We created Gust: A task orchestrator inspired by Airflow.
For those who have never heard about Aiflow, it’s a Python-based wor...
New
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
With AI doing more of the implementation work, I’ve been wondering how much coding I should deliberately keep doing myself.
My main conc...
New
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming










Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
eugene.kobil
@josevalim maybe you know?
deadtrickster
I think having exact line we suspect is useful - mongodb/lib/bson/encoder.ex at 21037d700fc8e9675d99b1d3c6b58ade2f6b61bb · elixir-mongo/mongodb · GitHub
eugene.kobil
Other interesting detail is that
impl_foron v.1.10.4 costs a lot when it returnsfalse(no implementation found).In case when it returns
trueperformance is almost equal to the v1.11impl_forversion.However in elixir v.1.11
impl_forworks always fast regardless if implementation was found or not.ltd
70ms for a single impl_for lookup? something else is amiss, how are you measuring this?
eugene.kobil
deadtrickster provided the link above to point where exact
impl_forhappens. Hope it can give some context.And it was not the worst case. I tried more series (~2k calls with different datatypes) and some series showed 100ms+ average.
However as I mentioned above it works that slow only when the protocol implementation is not found.
When implementation present (for Map) it works pretty fast, in 90% of cases it takes less then 20 microseconds.
Just with
josevalim
AFAIK we didn’t change anything around this so, if I had to guess, you are having an issue with protocol consolidation on previous versions. Perhaps the protocol was not consolidated for some reason?
ltd
thanks, i took 70ms as milliseconds, microseconds commonly abbreviated us.
I’m guessing measuring wall time around a single statement is susceptible, to context switch or other cpu/system activity. Maybe someone can suggest a better way to benchmark this.
ImNotAVirus
You can use benchfella or benchee for example if you need more “accurate” results.
eugene.kobil
You right!
I’ve checked it with
Protocol.consolidated?/1and it returnedfalseon v1.10.4 version buttrueon v.1.11But what is the reason of such behaviour?
I’ve set
consolidate_protocols: trueexplicitly both for mongodb and the project where I use it as a dependency.On both versions
Elixir.Mongo.Encoder.beamwas present into consolidated app directory (_build/**/lib/**/consolidated/), butElixir.Mongo.Encoder.Map.beampresented in_build/**/lib/mongodb/ebin/only on v1.11eugene.kobil
I mean exactly ~70ms (~70000 microseconds).