This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Since top-level data structures do not undergo DCE, what would be a reasonable compromise between optimizing bundle size and speed? Obviously top-level data structures can be reorganized into a function constantly returning the data to save on bundle size, but this also has negative performance impacts, doesn’t it? EDIT: I guess we could rely on Google Closure being able to statically infer function calls and paste data structures directly into functions using them. No idea if it is also capable of caching this constant value across functions calls, however.
delay
is an option. (def that-thing (delay {:big ["structure"]}))
, only downside is that you need @that-thing
, but that is reasonable
what kind of top level data structure are you talking about though? it can be much much better to keep the structure out of the code entirely. instead loading an .edn or .json or whatever file on startup.
I’m looking at a library that has a large map. Putting the map into a function reduces bundle size significantly.
Why is delay
better than a function, assuming that the data is static?
Derefing a delay is a process that's much more complex than calling a function.
it is not? a function re-creates the data structure every time you call it. a delay creates it once.
after that a deref is a protocol function call, so basically a regular function call. nothing more complex about it.
> a function re-creates the data structure every time you call it
Huh. That's not the case in CLJ. Why doesn't CLJS cache it? Is there a possibility for enhancement?
> after that a deref is a protocol function call
Ah, once again I'm trying to apply my knowledge of CLJ to CLJS. In CLJ, deref
uses instance?
.