feat: cache matchers with simple cache

[alisd23]

Cache matchers by key of pattern up to a maximum of 50 matchers. (arbitrary number).

If anyone has a better idea of what number to use for the cache max, let me know.

Relates to issue #3875

[ryanflorence]

Thanks for the PR :)

This dep adds 5kb to the gzipped build :( That's half the size of the whole lib in the first place, maybe there's a quick use-case specific implementation?

[alisd23]

Oh wow yeah I didn't think about that. I'll implement a simple cache and remove this lib 👍

[ryanflorence]

for example, we probably don't need a full-blown LRU cache. Maybe we can just say "hey, we have 5000 things cached, let's stop caching."

How many apps have 5000 routes? And of apps that have dynamic patterns (like the "recursive" example) they'll just get a tiny bit slower, but maybe not even noticeable because how many sub routes are they going to have dynamically? Am I making sense?

How much memory is 10,000 cached matchers? Maybe we cap it there and then see how things shake out in the real world.

[alisd23]

Yeah I do agree, I can't imagine many apps have more than even 100 unique routes, so this is only potentially solving a very edgy edge-case.

I would say caching like 500 at any time would be more than enough.

But another question is: is any caching necessary at all? How expensive is the pathToRegexp anyway. Surely any savings from skipping that are negligible?

[ryanflorence]

I don't have any records but i did a little console.time() fiddling and it seemed that a cache would be helpful since these get rendered a lot

[alisd23]

Fair enough, can't argue with evidence! A simple cache would seem to be the best solution then 👍

[alisd23]

@ryanflorence thoughts on this simpler cache?

[timdorr]

Nice! 👍 LGTM