---
url: /learn/speedup.md
description: Profiling and improving performance of popular projects across the ecosystem.
---

# Speedup

A major part of improving the ecosystem for everyone is *speed*. The speed of core packages, tools, and more can always be improved and will benefit the community as a whole.

A few groups and individuals are working in this space. Some examples include:

* [Speeding up the JavaScript Ecosystem](https://marvinh.dev/blog/speeding-up-javascript-ecosystem)

## Linting

Some performance improvements can be detected via a linter.

### ESLint

For those of us using ESLint, a few plugins are available which strongly align with the principals of the e18e effort:

| Plugin                                                                                | Description                                                                             |
| ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| [@e18e/eslint-plugin](https://github.com/e18e/eslint-plugin)                          | Official e18e plugin with rules for modernization, module replacements, and performance |
| [eslint-plugin-barrel-files](https://github.com/thepassle/eslint-plugin-barrel-files) | Detects barrel/index files                                                              |

### Biome

Biome supports some rules out of the box which align with e18e:

* [noBarrelFile](https://biomejs.dev/linter/rules/no-barrel-file/)
* [noReExportAll](https://biomejs.dev/linter/rules/no-re-export-all/)
* [noRestrictedDependencies](https://biomejs.dev/linter/rules/no-restricted-dependencies/) (module-replacements)

### Oxlint

Oxlint also supports a rule out of the box to prevent barrel files:

* [oxc/no-barrel-file](https://oxc.rs/docs/guide/usage/linter/rules/oxc/no-barrel-file.html)

## Coding Tips

The code you write plays an important role in the performance of your app. Some patterns are highlighted below for common pitfalls and ways to improve it. Remember to always profile your code when making performance changes!

### Avoid generators for hot code paths

At the moment, most JavaScript engines do not optimize [generator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Generator) function calls, which leads to a large performance hit if used extensively.

Prefer using non-async [iterators](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator) or plain arrays.

### Avoid chaining array methods

Chaining array methods like `map`, `filter`, `reduce`, etc. leads to many intermediate arrays being created and disposed, causing more work for the garbage collector. Each chain also leads to an extra iteration, which can be more times than needed.

Prefer using [`for` loops](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for), [`for...in` loops](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in), [`for...of` loops](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of) and [iterator methods](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator#instance_methods), which are lazy, or a single chain method only to prevent the caveats above.