Skip to content
This repository has been archived by the owner on Jan 19, 2021. It is now read-only.

Use binary search in the prioritized task executor #129

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

jochem-brouwer
Copy link
Member

In the Prioritized Task Executor originally every time when a task finishes, the priority list is sorted again. This is not optimal as we can do this directly when we insert it. For instance, _walkTrie is expected to get a gigantic queue at some point if we have a large MPT, which means we might be sorting this large array every time MPT finds a new item.

There is possibly one problem here: a task might finish while the insertion algorithm is ran. I think we need a lock mechanism here? Suggestions?

@jochem-brouwer
Copy link
Member Author

jochem-brouwer commented Sep 6, 2020

Added a lock. This is the first time I'm using this semaphore stuff, so please carefully review it 😄

Should fix the tests first though.

if (this.currentPoolSize < this.maxPoolSize) {
this.currentPoolSize++
fn(() => {
fn(async () => {
await this.lock.acquire()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks quite dangerous. If this callback gets executed and await right away you'd get into a deadlock, won't you?

That being said, I don't know much about this part of MPT. I was just casually looking at this because of your message on discord.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to update it because the tests are failing, but I don't think this will deadlock: if it's locked it means that some other Promise is running, which will unlock it at some point.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mind you are right 😅

@coveralls
Copy link

coveralls commented Sep 6, 2020

Coverage Status

Coverage increased (+0.08%) to 95.366% when pulling 4f0e150 on priority-queue-optimized into 0e6e1f7 on master.

@jochem-brouwer
Copy link
Member Author

Testing it on a Geth DB seems to hang, so need to battle-test this first.

@jochem-brouwer
Copy link
Member Author

jochem-brouwer commented Sep 7, 2020

Tested this on the mainnet DB of Geth. Surprisingly, this did not result in a big performance increase, my original task which took about 400 seconds went down to 380 seconds.

The code is rather complex currently and a bit all-over-the-place, will clean it up.

Flamegraph of above's task with ~25k states:
490217.0x.zip

Used console.log to track progress.

@jochem-brouwer
Copy link
Member Author

Ready for review

@holgerd77
Copy link
Member

Let's maybe wait for the benchmark work from @ryanio to get a bit clearer picture here. This is a lot of new code, I would rather want to see if it is worth to add that much of new complexity before merging in.

@jochem-brouwer
Copy link
Member Author

Yeah I agree, the performance increase seems (empirically) to be not that exciting and this code is rather complex. I am also not very confident at this point since I do not understand why the code fails to work if I put the acquire lock stuff at different places.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants