-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
[manifold] make partitioner faster. #3
Conversation
perf improvements.
@@ -31,7 +31,11 @@ defmodule Manifold.Partitioner do | |||
# Set optimal process flags | |||
Process.flag(:trap_exit, true) | |||
Process.flag(:message_queue_data, :off_heap) | |||
{:ok, Tuple.duplicate(nil, partitions)} | |||
workers = for _ <- 0..partitions do | |||
{:ok, pid} = Worker.start_link() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is probably a fine change. But this no longer supports respawning a worker if it somehow crashes. If you want to make this change you should remove :trap_exit
and the :EXIT
match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed.
this is clearly faster, i'm wanting to merge this then work on sharding partitions in #4. wdyt? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only change that seems worth it is the group by optimization.
Partitioner Optimizations
Utils.group_by
, we are using a new function calledUtils.partition_pids
which uses a tuple instead of a map internally. This ends up being roughly 2.2x faster thanUtils.group_by
in the benchmarks attached.state
not need to be modified during iteration. (pre-spawn the workers) in the Partitioner. This means we don't have to useEnum.reduce
and can instead use a more optimized code path for this,do_send
, which operates on a tuple of lists, and sends to the respective worker. Turns out this isn't really any faster...send
operation ends up being faster, as it doesn't have to start anEnum.reduce
r, or iterate over the result ofUtils.partition_pids
, so that avoids ~0.15µs/op + ~0.70-1.5 µs/op. additionally, this function consumes less reductions as it is doing less things (which we want!)worker gained some optimizations too:
Enum.each
(it's a little bit faster), here's sending to 200 pids:Manifold.send