Feature request: support for WeakMap

[amitm02]

If the arguments are very big, sometimes WeakMap is the only practical solution

[planttheidea]

Can you provide an example?

[amitm02]

Imagine there is a huge object of 1mb as an argument.

…

On Tue, 25 Feb 2020 at 15:51 Tony Quetano ***@***.***> wrote: Can you provide an example? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#43?email_source=notifications&email_token=AAONFH7YSYFBEOWDI3TLLTTREUO6FA5CNFSM4K27CWS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM4BAPY#issuecomment-590876735>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAONFHYURSSG6NDFXQJGNQLREUO6FANCNFSM4K27CWSQ> .

[planttheidea]

First of all, a weakmap doesn't change that size; a cache of 1 item without a weakmap and a cache of 1 item with a weakmap with that value incurs the same space consumption. The only difference is the garbage collection, where you need to specifically clear the cache without a weakmap.

Second, this library is built with practicality in mind; a real world use-case with explanation of how the existing functionality cannot support it and how a weakmap is the only solution would help.

This is not a planned feature at this time because the use of a weakmap prevents some of the capabilities of this library from being possible (LRU, cache size limit, etc.). However, if I can help you solve your use case, happy to try.

[amitm02]

Weak map allow for a very fast compression of the object of its not getting garbage collected. O(1) mo matter it's size. JSON.stringify() for example increase linearly with the size of the object. I implemented it in the past as a custom solution and thought it could be a good add-on to your library. But I understand you considerations.

…

On Tue, 25 Feb 2020 at 16:03 Tony Quetano ***@***.***> wrote: First of all, a weakmap doesn't change that size; a cache of 1 item without a weakmap and a cache of 1 item with a weakmap with that value incurs the same space consumption. The only difference is the garbage collection, where you need to specifically clear the cache without a weakmap. Second, this library is built with practicality in mind; a real world use-case with explanation of how the existing functionality cannot support it and how a weakmap is the only solution would help. This is not a planned feature at this time because the use of a weakmap prevents some of the capabilities of this library from being possible (LRU, cache size limit, etc.). However, if I can help you solve your use case, happy to try. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#43?email_source=notifications&email_token=AAONFHZ4LNYYKYUW5ZHE52DREUQMLA5CNFSM4K27CWS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEM4CKLI#issuecomment-590882093>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAONFH25I6AKFWMYH5DA4GLREUQMLANCNFSM4K27CWSQ> .

[planttheidea]

Just to be clear, this library does not use stringification, it uses SameValueZero equality of arguments. I know several libraries out there that claim to be fast but use stringification to handle key storage, but that is an architectural decision I disagree with and therefore did not incorporate.

If you are looking for weakmap support with a memoization library, try memoizee. It is not as fast, but it's more flexible for caching options, and it has a weakmap mode.

I would also recommend doing your own performance analysis instead of referring to academic concepts. While true in an absolute sense, the differences may be negligible. Look for the best combination of speed, footprint, and code simplicity. It may be your bespoke weakmap solution, it may be using only one library, or it may be multiple solutions.