3 ms·

- Flow understands the semantics of it. - The path can only be given as a static function literal and there is no function call overhead at runtime because of

• 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 ago
    The 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 ago
      Naw, Lodash is modular. You can cherry-pick its modules. It's less than 716 bytes (with lodash-webpack-plugin).