1 | # regex-cache [![NPM version](https://img.shields.io/npm/v/regex-cache.svg?style=flat)](https://www.npmjs.com/package/regex-cache) [![NPM monthly downloads](https://img.shields.io/npm/dm/regex-cache.svg?style=flat)](https://npmjs.org/package/regex-cache) [![NPM total downloads](https://img.shields.io/npm/dt/regex-cache.svg?style=flat)](https://npmjs.org/package/regex-cache) [![Linux Build Status](https://img.shields.io/travis/jonschlinkert/regex-cache.svg?style=flat&label=Travis)](https://travis-ci.org/jonschlinkert/regex-cache) [![Windows Build Status](https://img.shields.io/appveyor/ci/jonschlinkert/regex-cache.svg?style=flat&label=AppVeyor)](https://ci.appveyor.com/project/jonschlinkert/regex-cache)
|
2 |
|
3 | > Memoize the results of a call to the RegExp constructor, avoiding repetitious runtime compilation of the same string and options, resulting in surprising performance improvements.
|
4 |
|
5 | ## Install
|
6 |
|
7 | Install with [npm](https://www.npmjs.com/):
|
8 |
|
9 | ```sh
|
10 | $ npm install --save regex-cache
|
11 | ```
|
12 |
|
13 | * Read [what this does](#what-this-does).
|
14 | * See [the benchmarks](#benchmarks)
|
15 |
|
16 | ## Usage
|
17 |
|
18 | Wrap a function like this:
|
19 |
|
20 | ```js
|
21 | var cache = require('regex-cache');
|
22 | var someRegex = cache(require('some-regex-lib'));
|
23 | ```
|
24 |
|
25 | **Caching a regex**
|
26 |
|
27 | If you want to cache a regex after calling `new RegExp()`, or you're requiring a module that returns a regex, wrap it with a function first:
|
28 |
|
29 | ```js
|
30 | var cache = require('regex-cache');
|
31 |
|
32 | function yourRegex(str, opts) {
|
33 | // do stuff to str and opts
|
34 | return new RegExp(str, opts.flags);
|
35 | }
|
36 |
|
37 | var regex = cache(yourRegex);
|
38 | ```
|
39 |
|
40 | ## Recommendations
|
41 |
|
42 | ### Use this when...
|
43 |
|
44 | * **No options are passed** to the function that creates the regex. Regardless of how big or small the regex is, when zero options are passed, caching will be faster than not.
|
45 | * **A few options are passed**, and the values are primitives. The limited benchmarks I did show that caching is beneficial when up to 8 or 9 options are passed.
|
46 |
|
47 | ### Do not use this when...
|
48 |
|
49 | * **The values of options are not primitives**. When non-primitives must be compared for equality, the time to compare the options is most likely as long or longer than the time to just create a new regex.
|
50 |
|
51 | ### Example benchmarks
|
52 |
|
53 | Performance results, with and without regex-cache:
|
54 |
|
55 | ```bash
|
56 | # no args passed (defaults)
|
57 | with-cache x 8,699,231 ops/sec ±0.86% (93 runs sampled)
|
58 | without-cache x 2,777,551 ops/sec ±0.63% (95 runs sampled)
|
59 |
|
60 | # string and six options passed
|
61 | with-cache x 1,885,934 ops/sec ±0.80% (93 runs sampled)
|
62 | without-cache x 1,256,893 ops/sec ±0.65% (97 runs sampled)
|
63 |
|
64 | # string only
|
65 | with-cache x 7,723,256 ops/sec ±0.87% (92 runs sampled)
|
66 | without-cache x 2,303,060 ops/sec ±0.47% (99 runs sampled)
|
67 |
|
68 | # one option passed
|
69 | with-cache x 4,179,877 ops/sec ±0.53% (100 runs sampled)
|
70 | without-cache x 2,198,422 ops/sec ±0.47% (95 runs sampled)
|
71 |
|
72 | # two options passed
|
73 | with-cache x 3,256,222 ops/sec ±0.51% (99 runs sampled)
|
74 | without-cache x 2,121,401 ops/sec ±0.79% (97 runs sampled)
|
75 |
|
76 | # six options passed
|
77 | with-cache x 1,816,018 ops/sec ±1.08% (96 runs sampled)
|
78 | without-cache x 1,157,176 ops/sec ±0.53% (100 runs sampled)
|
79 |
|
80 | #
|
81 | # diminishing returns happen about here
|
82 | #
|
83 |
|
84 | # ten options passed
|
85 | with-cache x 1,210,598 ops/sec ±0.56% (92 runs sampled)
|
86 | without-cache x 1,665,588 ops/sec ±1.07% (100 runs sampled)
|
87 |
|
88 | # twelve options passed
|
89 | with-cache x 1,042,096 ops/sec ±0.68% (92 runs sampled)
|
90 | without-cache x 1,389,414 ops/sec ±0.68% (97 runs sampled)
|
91 |
|
92 | # twenty options passed
|
93 | with-cache x 661,125 ops/sec ±0.80% (93 runs sampled)
|
94 | without-cache x 1,208,757 ops/sec ±0.65% (97 runs sampled)
|
95 |
|
96 | #
|
97 | # when non-primitive values are compared
|
98 | #
|
99 |
|
100 | # single value on the options is an object
|
101 | with-cache x 1,398,313 ops/sec ±1.05% (95 runs sampled)
|
102 | without-cache x 2,228,281 ops/sec ±0.56% (99 runs sampled)
|
103 | ```
|
104 |
|
105 | ## Run benchmarks
|
106 |
|
107 | Install dev dependencies:
|
108 |
|
109 | ```bash
|
110 | npm i -d && npm run benchmarks
|
111 | ```
|
112 |
|
113 | ## What this does
|
114 |
|
115 | If you're using `new RegExp('foo')` instead of a regex literal, it's probably because you need to dyamically generate a regex based on user options or some other potentially changing factors.
|
116 |
|
117 | When your function creates a string based on user inputs and passes it to the `RegExp` constructor, regex-cache caches the results. The next time the function is called if the key of a cached regex matches the user input (or no input was given), the cached regex is returned, avoiding unnecessary runtime compilation.
|
118 |
|
119 | Using the RegExp constructor offers a lot of flexibility, but the runtime compilation comes at a price - it's slow. Not specifically because of the call to the RegExp constructor, but **because you have to build up the string before `new RegExp()` is even called**.
|
120 |
|
121 | ## About
|
122 |
|
123 | ### Contributing
|
124 |
|
125 | Pull requests and stars are always welcome. For bugs and feature requests, [please create an issue](../../issues/new).
|
126 |
|
127 | ### Contributors
|
128 |
|
129 | | **Commits** | **Contributor** |
|
130 | | --- | --- |
|
131 | | 31 | [jonschlinkert](https://github.com/jonschlinkert) |
|
132 | | 1 | [MartinKolarik](https://github.com/MartinKolarik) |
|
133 |
|
134 | ### Building docs
|
135 |
|
136 | _(This project's readme.md is generated by [verb](https://github.com/verbose/verb-generate-readme), please don't edit the readme directly. Any changes to the readme must be made in the [.verb.md](.verb.md) readme template.)_
|
137 |
|
138 | To generate the readme, run the following command:
|
139 |
|
140 | ```sh
|
141 | $ npm install -g verbose/verb#dev verb-generate-readme && verb
|
142 | ```
|
143 |
|
144 | ### Running tests
|
145 |
|
146 | Running and reviewing unit tests is a great way to get familiarized with a library and its API. You can install dependencies and run tests with the following command:
|
147 |
|
148 | ```sh
|
149 | $ npm install && npm test
|
150 | ```
|
151 |
|
152 | ### Author
|
153 |
|
154 | **Jon Schlinkert**
|
155 |
|
156 | * [github/jonschlinkert](https://github.com/jonschlinkert)
|
157 | * [twitter/jonschlinkert](https://twitter.com/jonschlinkert)
|
158 |
|
159 | ### License
|
160 |
|
161 | Copyright © 2017, [Jon Schlinkert](https://github.com/jonschlinkert).
|
162 | Released under the [MIT License](LICENSE).
|
163 |
|
164 | ***
|
165 |
|
166 | _This file was generated by [verb-generate-readme](https://github.com/verbose/verb-generate-readme), v0.6.0, on September 01, 2017._ |
\ | No newline at end of file |