Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add benchmarking scripts

Open
#80 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
javascript
Domain
ci-cd, performance, tooling

Research direction

Start by reviewing the benchmark-like cases in test/generate.test.js, the proposed bench/ convention, and the existing .travis.yml configuration. Define stable local inputs, configurable concurrency, shareable output, and CI execution that checks for breakage without evaluating timing; done means the scripts cover performance or memory checks without network I/O.

Written by the indexing model from the issue text.

Description

estimate-8 groomed jira-sync-complete p3

For many types of changes (such as #76 and #78, recently) it would be great to have a set of benchmarking scripts for assessing performance impacts.

spritezero does currently have some unit-tests that function sort of like benchmarking (see here) but it is not ideal to have these mixed in with unit tests.

Benchmarking scripts guidelines:

  • Should live in the bench/ directory, following convention of other repos (ex https://github.com/mourner/rbush/tree/master/bench).
  • Can be run locally to assess if changes to spritezero deps or code have an impact on performance or memory usage
  • Should do no network, only local i/o
  • Should be primarily designed to be run locally and used for collaborative testing
  • Should nevertheless be run on CI (with explicit lines added to the .travis.yml to run them) to ensure they don't break (since they should not run as unit tests). But we should ignore their timing result on CI - the only purpose is to make sure they don't break under refactors.
  • Should dump their output in an easy to share format that can be posted on tickets and referred back to
  • Data input should be stable over time so their results can be compared across time with git bisect
  • Should have configurable concurrency and should not default to using os.cpus() otherwise results will not be very comparable across machines.

(h/t @springmeyer for this list)

Dominant language
JavaScript
Stars
186
Forks
70
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mapbox/spritezero

All issues in mapbox/spritezero

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.