You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: chapters/calls.asciidoc
+4-5Lines changed: 4 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,7 +39,7 @@ version will become old and the third version will be loaded as the
39
39
current version.
40
40
41
41
=== Hot Code Loading
42
-
As we saw there is not only a syntactic difference but
42
+
As we saw there is not only a syntactic difference but
43
43
also a semantic difference between a local function call and a remote function call.
44
44
A remote call, or a "fully quallified call", that is a call to a
45
45
function in a named module, is guaranteed to go to the latest loaded
@@ -157,7 +157,7 @@ Result = M:F(fun(X) -> X * 2 end, [1,2,3]).
157
157
```
158
158
159
159
This dynamic invocation technique is less efficient than direct calls but provides flexibility in selecting execution paths at runtime.
160
-
This can be used to implement a callback system where the a module that exports a specific set of functions and you just pass the module name around.
160
+
This can be used to implement a callback system where the module that exports a specific set of functions and you just pass the module name around.
161
161
This technique makes it much harder for analytic tools like Dialyzer to find errors in the code since the call graph is not known at compile time.
162
162
163
163
@@ -189,13 +189,12 @@ Function call efficiency in Erlang follows a clear hierarchy, as outlined in the
189
189
190
190
Explicit calls, both local and remote (`foo()`, `m:foo()`) are the most efficient.
191
191
I would like to add that the most efficient call is a local call to a function in the same module. This is because the call can be resolved at compile time and the function can be inlined. This is not possible for a remote call since the module can be changed at runtime.
192
-
Even though the JIT compiler can do a good job with remote calls it does not inline them as of OTP 27.
192
+
Even though the JIT compiler can do a good job with remote calls it does not inline them as of OTP 27.
193
193
194
194
Calling a closure (`Fun()`, `apply(Fun, [])`) is slightly slower but still efficient.
195
195
196
-
Applying a function () (`Mod:Name()`, `apply(Mod, Name, [])`) with a known number of arguments at compile time is next in efficiency. (You can not apply a function that is not exported from a module.)
196
+
Applying a function () (`Mod:Name()`, `apply(Mod, Name, [])`) with a known number of arguments at compile time is next in efficiency. (You can not apply a function that is not exported from a module.)
197
197
198
198
Applying an exported function with an unknown number of arguments (`apply(Mod, Name, Args)`) is the least efficient.
199
199
200
200
The Erlang runtime system is optimized for local calls and remote calls to the current version of a module. Hot code loading is a powerful feature that enables live updates to running systems, but it comes with performance trade-offs. It is also important to understand that reloading a module two times will purge the old version of the module and any references to it will crash the process holding the reference.
0 commit comments