4 ms·
Is the FN call overhead really that horrible in lodash? I didn't see any side by side comps. Also, the transformed code (like all transformed babel) is most li
by arrty88 10y ago
Is the FN call overhead really that horrible in lodash? I didn't see any side by side comps.
Also, the transformed code (like all transformed babel) is most likely ugly and more verbose than using lodash's get, no?
- glibgil 10y agoThe function call overhead is in browsers and in node, but it is low. Inlining is a top priority for all JavaScript implementations. However, I wonder why lodash doesn't use a lambda. Parsing that path seems silly. It could just be a try on a lambda https://github.com/lodash/lodash/blob/master/.internal/baseGet.js https://github.com/lodash/lodash/blob/master/.internal/baseG...
- 15155 10y ago> Is the FN call overhead really that horrible in lodash? The overall size overhead is what is horrible. > Also, the transformed code (like all transformed babel) is most likely ugly and more verbose than using lodash's get, no? Yes, but it also performs at what is probably as-close-to-optimal as possible. The resulting ternaries are extremely easy to work with for even the most basic of JS compilers. Source maps work well - I don't see this as a downside at all.
- deleted 10y ago[deleted]
- jdd 10y agoNaw, Lodash is modular. You can cherry-pick its modules. It's less than 716 bytes (with lodash-webpack-plugin).