Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve jest-worker (up to 4x) #5793

Merged
merged 3 commits into from
Mar 14, 2018
Merged

Improve jest-worker (up to 4x) #5793

merged 3 commits into from
Mar 14, 2018

Conversation

mjesun
Copy link
Contributor

@mjesun mjesun commented Mar 14, 2018

This PR modifies the way internal worker queues are managed, passing from an array to a linked-list, improving a 10% the current benchmark, and 400% over a new benchmark.

How come this wasn't noticed before?

When jest-worker was initially benchmarked, it was done by using not so many jobs (~10k), but very heavy in time. While this is the usual approach (few jobs, lots of time per job), sometimes you have the opposite (i.e. lots of jobs, but each of them very fast). This is actually what jest-haste-map does.

Since the internal queue was an array, re-indexing the queue is a O(n) operation, which becomes especially relevant on the second scenario. Switching to a linked list means that all operations for advancing the queue become O(1), no matter its length. This results in massive speed improvements on really long queues.

Some benchmarks

Using the extended performance test, the empty function, called 100,000 times results in:

---------------------------------------------------------------------------
jest-worker: { globalTime: 11102, processingTime: 11058 }
worker-farm: { globalTime: 9713, processingTime: 9685 }
---------------------------------------------------------------------------
jest-worker: { globalTime: 10790, processingTime: 10762 }
worker-farm: { globalTime: 10453, processingTime: 10432 }
---------------------------------------------------------------------------
jest-worker: { globalTime: 11111, processingTime: 11079 }
worker-farm: { globalTime: 10133, processingTime: 10112 }
---------------------------------------------------------------------------

Now, with the change, it results in:

---------------------------------------------------------------------------
jest-worker: { globalTime: 2634, processingTime: 2594 }
worker-farm: { globalTime: 10165, processingTime: 10141 }
---------------------------------------------------------------------------
jest-worker: { globalTime: 2780, processingTime: 2756 }
worker-farm: { globalTime: 10132, processingTime: 10110 }
---------------------------------------------------------------------------
jest-worker: { globalTime: 2608, processingTime: 2581 }
worker-farm: { globalTime: 10295, processingTime: 10272 }
---------------------------------------------------------------------------

What about the existing metrics?

The previous metric (which we initially used for benchmarking, loadTest called 10,000 times), has also improved, but only slightly, since that one was already optimized:

---------------------------------------------------------------------------
jest-worker: { globalTime: 726, processingTime: 690 }
worker-farm: { globalTime: 769, processingTime: 748 }
---------------------------------------------------------------------------
jest-worker: { globalTime: 719, processingTime: 693 }
worker-farm: { globalTime: 784, processingTime: 765 }
---------------------------------------------------------------------------
jest-worker: { globalTime: 703, processingTime: 673 }
worker-farm: { globalTime: 748, processingTime: 731 }
---------------------------------------------------------------------------

Tests

I ensured all tests pass, but I also added some slight modifications into the __performance__tests__ so that you can pass an arbitrary worker method as well as an arbitrary number of iterations. This allowed me to test the other scenario.

On a personal note: this is actually WHY algorithms and data structures knowledge IS important for a frontend developer! 🙂

@codecov-io
Copy link

Codecov Report

Merging #5793 into master will decrease coverage by <.01%.
The diff coverage is 80.95%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #5793      +/-   ##
==========================================
- Coverage   63.74%   63.73%   -0.01%     
==========================================
  Files         216      216              
  Lines        7929     7938       +9     
  Branches        4        3       -1     
==========================================
+ Hits         5054     5059       +5     
- Misses       2874     2878       +4     
  Partials        1        1
Impacted Files Coverage Δ
packages/jest-worker/src/types.js 100% <ø> (ø) ⬆️
...r/src/__performance_tests__/workers/jest_worker.js 0% <0%> (ø) ⬆️
...r/src/__performance_tests__/workers/worker_farm.js 0% <0%> (ø) ⬆️
packages/jest-worker/src/worker.js 98.27% <94.44%> (-1.73%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f588a60...45536f5. Read the comment docs.

@@ -49,12 +49,13 @@ export default class {
_busy: boolean;
_child: ChildProcess;
_options: WorkerOptions;
_queue: Array<QueueChildMessage>;
_queue: ?QueueChildMessage;
_last: ?QueueChildMessage;
Copy link
Member

Choose a reason for hiding this comment

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

this is not in the right alphabetical location :P

Copy link
Contributor Author

Choose a reason for hiding this comment

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

😄

@cpojer cpojer merged commit f1922ad into jestjs:master Mar 14, 2018
@cpojer
Copy link
Member

cpojer commented Mar 14, 2018

This is really fantastic. Thanks @mjesun, great work!

@mjesun mjesun deleted the improve-jest-worker branch March 14, 2018 15:17
@rickhanlonii
Copy link
Member

Beauty!!

@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
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.

5 participants