Probably both: we don't see the Date constructor much when profiling things, and we don't expect that a whole lot could be gained when trying to make it faster, so the effort-to-benefit ratio is probably just not worth it.
Out of *my *curiosity: what problem are you solving by "using Date.now & new Date quite a bit"? On Tue, Jun 9, 2020 at 11:19 AM Paweł Badeński <pawel.baden...@gmail.com> wrote: > Thanks for the context! To that point - do you know if optimising Date has > ever been a topic of conversation? I'm curious if it's just impossible/very > hard or just never been a priority. > > On Monday, 8 June 2020 16:18:10 UTC+1, Jakob Kummerow wrote: >> >> Due to how complicated <https://tc39.es/ecma262/#sec-date-constructor> >> the Date constructor is, it is expected to be much slower than >> allocating an object. Beyond the sheer amount of stuff it has to do per >> spec, this is amplified by the fact that the more complicated (and the less >> frequently performed) an operation is, the more likely engines are to >> implement it in a slower (but more manageable) fashion. Specifically, >> object allocation has all sorts of fast paths like inlining in optimized >> code, which new Date(...) doesn't have. >> >> >> On Mon, Jun 8, 2020 at 11:38 AM Paweł Badeński <pawel....@gmail.com> >> wrote: >> >>> That's all fair enough. Shouldn't then constructing via some >>> constructors be faster - where it doesn't require operating system call? >>> Because I'm still seeing rather slow calls.. >>> >>> new Date(1591386221897) x 9,329,719 ops/sec ±2.66% (64 runs sampled) >>> >>> new Date(2019, 1, 1, 12, 0, 1, 1) x 2,636,300 ops/sec ±0.83% (65 runs >>> sampled) >>> >>> Date.UTC(2019, 1, 1, 12, 0, 1, 1) x 11,741,842 ops/sec ±0.79% (65 runs >>> sampled) >>> >>> >>> Source: https://stackblitz.com/edit/js-dvq8ri >>> >>> On Friday, 5 June 2020 20:14:02 UTC+1, Jakob Kummerow wrote: >>>> >>>> Yes, getting the current time from the operating system is >>>> significantly slower than allocating a simple JS object like [1, 2, 3]. >>>> That's not going to change. >>>> >>>> As you can see, Date.now() is significantly faster than new Date(), so >>>> that's preferable when performance/overhead matters. Other than that, I'd >>>> simply recommend not to call either function overly often -- they have >>>> millisecond resolution, so calling them very frequently just means that >>>> you'll get the same values back repeatedly. >>>> >>>> In particular, I've seen folks try to get profiling data by calling >>>> Date.now() before and after each function call. For small functions, >>>> that's not a good idea, because you'll mostly be measuring the overhead of >>>> the Date.now() calls themselves. When you need to profile, use a >>>> profiler. (I've seen microbenchmarks where profiling revealed that half the >>>> time was spent in Date.now() calls!) >>>> >>>> If you want to perform some cheap action repeatedly before a timer runs >>>> out, it can help to have a double loop, e.g.: >>>> >>>> while (Date.now() < deadline) { >>>> // Try a bunch of times, not just once. >>>> for (let i = 0; i < 1000; i++) { >>>> very_quick_thing(); >>>> } >>>> } >>>> >>>> Tune the 1000 in the example until you see that the for-loop takes >>>> about a millisecond to finish (if it's accurate to an order of magnitude, >>>> i.e. between 0.1 and 10ms, that's good enough, and gives you some >>>> robustness towards hardware differences). >>>> >>>> >>>> On Fri, Jun 5, 2020 at 9:02 PM Al Mo <almo...@gmail.com> wrote: >>>> >>>>> [Warning. mere speculation] >>>>> >>>>> Perhaps it has to do with having to make a system call to get the >>>>> current time. >>>>> >>>>> Alex. >>>>> >>>>> On Fri, Jun 5, 2020 at 1:57 PM Paweł Badeński <pawel....@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Wondering if someone can help with a bit of context to satisfy mu >>>>>> curiosity! :D >>>>>> >>>>>> We are using Date.now & new Date quite a bit in our application >>>>>> (financial domain). I run a few micro-benchmarks and was wondering why do >>>>>> these report being relatively slow (as compared to construction of other >>>>>> objects). In fact all Date methods seem rather slow. Am I having wrong >>>>>> expectations for these to be faster? Are they as fast as they could be, >>>>>> or >>>>>> is it that Date just never got enough love in terms of performance >>>>>> optimizations? Really curious to get more color on this! >>>>>> >>>>>> Benchmarks: >>>>>> >>>>>> Date.now() x 9,454,436 ops/sec ±1.09% (65 runs sampled) >>>>>> >>>>>> new Date() x 5,594,688 ops/sec ±1.87% (64 runs sampled) >>>>>> >>>>>> [1, 2, 3] x 124,719,052 ops/sec ±0.90% (64 runs sampled) >>>>>> >>>>>> { a: 1, b: 2, c: 3 } x 112,368,878 ops/sec ±0.83% (65 runs sampled) >>>>>> >>>>>> new Object({ a: 1, b: 2, c: 3 }) x 32,547,566 ops/sec ±0.64% (64 runs >>>>>> sampled) >>>>>> >>>>>> Source: https://stackblitz.com/edit/js-dvq8ri >>>>>> >>>>>> Thanks! >>>>>> Pawel >>>>>> >>>>>> -- >>>>>> -- >>>>> >>>>> -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-users/5937ddba-e8f2-40c7-90f9-99f09578ccf9o%40googlegroups.com > <https://groups.google.com/d/msgid/v8-users/5937ddba-e8f2-40c7-90f9-99f09578ccf9o%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/CAKSzg3TU7j-FjtPtdTDL%3DXkE1qSPehXCz5XgwF2E_xDF3uuwFQ%40mail.gmail.com.
