Improve runtime performance

[sindresorhus]

Chalk is already fast enough for most usage. Benchmarks in readme's like this one are silly because no one will run Chalk in a constant loop, and second they're also false, because those packages do less things than Chalk, so of course they're faster. However, that doesn't mean we shouldn't try to be as fast as possible.

Some things we could consider:

• Adding fast-paths for common use-cases. I think most people just do chalk.red(), chalk.bold.green(), etc (Meaning only 16 colors). We could add some fast-paths for those cases.
• Caching whenever possible.
• Experiment with using Proxy. This would reduce our method usage, but might add different kinds of overhead. Needs to me measured.
• Other things. Open to ideas.

Solving this tasks should also include measuring performance in DevTools and improving the benchmark file in this repo.

Chalk targets Node.js 8, but the optimizations should target Node.js 10.

This is a difficult issue and if you want to tackle it you're expected to have a deep level of understanding of JS and be familiar with measuring performance in DevTools.

---

IssueHunt Summary

stroncium has been rewarded.

Backers (Total: $100.00)

• issuehunt ($100.00)

Submitted pull Requests

• #337 Speed Buff Lvl. 129

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

---

IssueHunt has been backed by the following sponsors. Become a sponsor

[Qix-]

Meaning only 16-bit colors

4-bit*, 16 total.

We could add some fast-paths for those cases.

Such as?

Caching whenever possible.

You mean memoizing?

Experiment with using Proxy. This would reduce our method usage, but might add different kinds of overhead. Needs to me measured.

Proxy has a really bad history of being slow (I remember really wanting them when they came out for some ORM-type of code that just wasn't performant).

But of course, let's indeed measure it.

[sindresorhus]

We could add some fast-paths for those cases.

Such as?

That should be based on performance measurement, but one idea is to not load color-convert in those cases.

You mean memoizing?

Yes

Proxy has a really bad history of being slow (I remember really wanting them when they came out for some ORM-type of code that just wasn't performant).

It has improved a lot in recent V8 versions.

https://v8.dev/blog/optimizing-proxies

[IssueHuntBot]

@IssueHunt has funded $100.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[issuehunt-oss]

@sindresorhus has rewarded $90.00 to @stroncium. See it on IssueHunt

• 💰 Total deposit: $100.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $10.00