lukechilds / base64-async

95%

master: 100%

LAST BUILD ON BRANCH limit-concurrency

branch: limit-concurrency

CHANGE BRANCH

x

Reset

• limit-concurrency
• master
• v0.0.1
• v1.0.0
• v2.0.0
• codec
• decode-in-js
• v2.1.1
• v2.1.2
• greenkeeper/initial
• improve-bench
• greenkeeper/nyc-11.0.3
• greenkeeper/ava-0.20.0
• v2.1.3
• greenkeeper/ava-0.21.0
• greenkeeper/nyc-11.1.0
• greenkeeper/ava-0.22.0
• greenkeeper/nyc-11.2.0
• greenkeeper/nyc-11.2.1
• greenkeeper/coveralls-2.13.2
• greenkeeper/coveralls-2.13.3
• greenkeeper/coveralls-3.0.0
• greenkeeper/eslint-config-xo-lukechilds-1.0.1
• greenkeeper/ava-0.23.0
• greenkeeper/nyc-11.3.0
• greenkeeper/ava-0.24.0
• greenkeeper/nyc-11.4.1
• greenkeeper/ava-0.25.0
• greenkeeper/nyc-11.6.0
• greenkeeper/nyc-11.7.1
• greenkeeper/update-to-node-10
• greenkeeper/pretty-bytes-5.0.0
• greenkeeper/nyc-11.8.0
• greenkeeper/nyc-12.0.2
• greenkeeper/pretty-bytes-5.1.0
• greenkeeper/nyc-13.2.0
• greenkeeper/nyc-13.3.0
• greenkeeper/coveralls-3.0.3
• greenkeeper/time-span-3.0.0
• greenkeeper/time-span-3.1.0
• greenkeeper/nyc-14.0.0
• greenkeeper/pretty-bytes-5.2.0
• greenkeeper/nyc-14.1.0
• greenkeeper/nyc-14.1.1
• greenkeeper/coveralls-3.0.4
• greenkeeper/pretty-bytes-5.3.0
• greenkeeper/coveralls-3.0.6
• greenkeeper/coveralls-3.0.7

Build # 73

Build Type

push

travis-ci

Committed by lukechilds

Commit Message

Limit how many chunks can be worked in each setImmediate loop

Otherwise it can still block via lots of concurrent jobs. e.g 100 concurrent jobs with a chunk size of 250KB each means that 100 250KB chunks will be worked in each setImmediate loop.

Doesn't seem to make a performance diference. I'm not sure this actualy works...

Run Details

18 of 20 branches covered (90.0%)

Branch coverage included in aggregate %.

51 of 53 relevant lines covered (96.23%)

19.47 hits per line