| Age | Commit message (Collapse) | Author |
|---|
|
Avoid traversing all of the list/string when only part of it will be
used. An explicit check that the list is flat is needed since
string:slice() accepts deep lists and more.
|
|
* hasse/stdlib/optimize_calendar_rfc3339/OTP-15630:
stdlib: Optimize calendar:system_time_to_rfc3339()
|
|
The phrasing "no process can access the ETS table in the middle of the
operation" implies that the entire table is looked during
the operation, which is not true if `write_concurrency`
is enabled.
|
|
Not using io_lib for formatting makes the conversion several times
faster.
|
|
Long atom names in combination with <c><<>></c> could cause a crash.
|
|
* maint-21:
Updated OTP version
Prepare release
|
|
maint
* hasse/stdlib/optimize_pretty_print/ERIERL-306/OTP-15573:
Update primary bootstrap
stdlib: Optimize formatted printing of terms
|
|
Add ETS docs about partially bound key traversal
|
|
|
|
Fix bug in binary:encode_unsigned causing a read of uninitialized memory
|
|
Try calling iolist_size() before calling string:length().
The reason is that calls to string:length/1 are slow when the argument
is not a list of integers (or contains UNICODE).
|
|
* FNickRU/stdlib/optimize_calendar/PR-2121/OTP-15572:
Optimize calendar:gregorian_days_to_date/1
|
|
|
|
|
|
This patch improves the performance of calendar:gregorian_days_to_date/1
by changing the algorithm for finding the year to log-logarithmic.
The old implementation has linear complexity, which makes function
too slow for large values.
For example:
There is an API that allows you to create events for future dates.
There are users of this API who, for some reasons, choose dates
very far in the future. In such conditions, function works very slow.
New implementation based on interpolation search, takes 1 or 2
iterations at most cases and free from such a flaw.
A unit test was also developed to illustrate the speed of a function
at large values.
|
|
The bug could be seen by running the test that is added by this commit
in a valgrind enabled emulator.
Co-authored-by: John Högberg <[email protected]>
|
|
Clarify ETS docs about table iterations
|
|
|
|
* sverker/fix-since-clauses/OTP-15460:
Fix "since" for all multi clause functions
|
|
Fixes in erl_parse:abstract_type/0 type
|
|
This is the result of going through all .xml files
with "clause_i" attributes and make sure
their "since" versions are correct.
|
|
`search/2` was sorted incorrectly.
|
|
Fix remote-call error in ms_transform
|
|
Add missing list wrapper.
|
|
`af_function_type()` already contains the `{'type', anno(), 'fun', ...}`
tuple so it does not have to be wrapped again.
|
|
This is allowed since 19.3 (commit 6d238032) and documented since commit
744fb920.
|
|
|
|
|
|
introduced after OTP_R13B03.
|
|
|
|
The example should not show the iterator as that is
an internal value and if changed can confuse the reader
of the documentation. See ERL-796
|
|
* dgud/stdlib/unicode-binary-bug/ERL-777/OTP-15428:
unicode_util did not handle binary input data correctly
|
|
RFC3339 mentions in paragraph 5.1 that if certain conditions are
fulfilled, then sorting date and time strings results in a
time-ordered sequence. One of the conditions is that the strings must
have the same number of fractional second digits. This commits makes
sure this is indeed the case.
|
|
An external fun could inadvertently suppress warnings for
unused variables, such as in this example:
bug() ->
BugVar = foo(),
if true ->
fun m:f/1
end.
There would be no warning that `BugVar` was unused.
The bug was introduced in ff432e262e652, which was the commit
that extended external funs to allow variables.
https://bugs.erlang.org/browse/ERL-762
|
|
gc_zwj sent binaries recursivly to gc_extend/3 which didn't handle
can't handle them.
ERL-777
|
|
Before this patch the following call resulted in the below error
```
1> dbg:fun2ms(fun(_) -> m:f() end).
Error: Unknown error code {122,m,f}
```
Now it is properly formatted as
```
1> dbg:fun2ms(fun(_) -> m:f() end).
Error: fun containing the remote function call 'm:f/0' (called in body) cannot be translated into match_spec
```
|
|
* maint-18:
Updated OTP version
Prepare release
Optimize operator '--' and yield on large inputs
Conflicts:
OTP_VERSION
erts/doc/src/notes.xml
erts/emulator/beam/erl_alloc.types
erts/emulator/beam/erl_bif_lists.c
erts/vsn.mk
lib/stdlib/doc/src/notes.xml
lib/stdlib/vsn.mk
make/otp_version_tickets
otp_versions.table
|
|
|
|
* john/erts/OTP-18.3.4/minusminus_trapping/OTP-15371:
Optimize operator '--' and yield on large inputs
|
|
* maint-20:
Updated OTP version
Prepare release
Optimize operator '--' and yield on large inputs
Conflicts:
OTP_VERSION
erts/doc/src/notes.xml
erts/emulator/beam/erl_alloc.types
erts/emulator/beam/erl_bif_lists.c
erts/vsn.mk
lib/ssl/doc/src/notes.xml
lib/ssl/vsn.mk
lib/stdlib/doc/src/notes.xml
lib/stdlib/vsn.mk
make/otp_version_tickets
otp_versions.table
|
|
|
|
* john/erts/OTP-20.3.8/minusminus_trapping/OTP-15371:
Optimize operator '--' and yield on large inputs
|
|
The removal set now uses a red-black tree instead of an array on
large inputs, decreasing runtime complexity from `n*n` to
`n*log(n)`. It will also exit early when there are no more items
left in the removal set, drastically improving performance and
memory use when the items to be removed are present near the head
of the list.
This got a lot more complicated than before as the overhead of
always using a red-black tree was unacceptable when either of the
inputs were small, but this compromise has okay-to-decent
performance regardless of input size.
Co-authored-by: Dmytro Lytovchenko <[email protected]>
|
|
The removal set now uses a red-black tree instead of an array on
large inputs, decreasing runtime complexity from `n*n` to
`n*log(n)`. It will also exit early when there are no more items
left in the removal set, drastically improving performance and
memory use when the items to be removed are present near the head
of the list.
This got a lot more complicated than before as the overhead of
always using a red-black tree was unacceptable when either of the
inputs were small, but this compromise has okay-to-decent
performance regardless of input size.
Co-authored-by: Dmytro Lytovchenko <[email protected]>
|
|
* john/erts/minusminus_trapping/OTP-15371:
Optimize operator '--' and yield on large inputs
Inline erts_cmp
Clarify a magical allocation size
Fix trapping in lists:reverse/2
|
|
The removal set now uses a red-black tree instead of an array on
large inputs, decreasing runtime complexity from `n*n` to
`n*log(n)`. It will also exit early when there are no more items
left in the removal set, drastically improving performance and
memory use when the items to be removed are present near the head
of the list.
This got a lot more complicated than before as the overhead of
always using a red-black tree was unacceptable when either of the
inputs were small, but this compromise has okay-to-decent
performance regardless of input size.
Co-authored-by: Dmytro Lytovchenko <[email protected]>
|
|
It returns `ok`, instead of `noreply`.
|
|
beam_lib: Clarify the beam() type in code and documentation
OTP-15378
|
|
The type `beam()` in the `beam_lib` module is confusing:
-type beam() :: module() | file:filename() | binary().
It says that the module name can be used to identify the BEAM module
to be accessed, but passing in the module name only works if the BEAM
file is located in the current working directory because the module
is not searched for in the code path.
The reason that it is allowed to pass in the module name as an atom is
for backward compatibility. A long time ago, atoms instead of strings
were used as filenames. For that reason, `filename` and `file` still
accept atoms as filenames (although the practice is frown
upon). `beam_lib` accepts an atom as the filename for the same reason.
To remove the confusion, remove `module()` from the type and the
mention of it in the documentation. Code that uses an atom as a
filename will still work, but Dialyzer will issue a warning.
https://bugs.erlang.org/browse/ERL-696
|
|
* siri/cuddle:
Fix gen_fsm_SUITE:start2/1 to terminate process synchronously
Fix sys_SUITE:special_process/1 to terminating process synchronously
|
