Performance bottleneck creating a range using a start and end date

[dteirney]

We've run into a performance challenge using moment-range when creating a range using a start and end date.

We've tracked the challenge down to https://github.com/rotaready/moment-range/blob/master/lib/moment-range.js#L335

With the current implementation:

• hasOwnProperty is always called regardless of the type of start
• hasOwnProperty expects a string, so start always has toString() evaluated.
• for moment dates, toString() is nontrivial and chews through lots of CPU cycles
• toString() returns a string that will never be found as a property in the internal INTERVALS object (since it's a formatted date and not what is expected, e.g. 'year', 'month', 'day')

If using hasOwnProperty is indeed the best way to hold the valid set of strings for the code path in that if block, then adding a typeof start === "string" check would avoid all that toString() date formatting work.

[gf3]

great call! thanks for pointing this out. maybe we can sneak a fix into the 4.0.0 release

[TristanJM]

Thanks for this suggestion 😃

Created PR:
#243

Feel free to double check my benchmarks!