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 > <javascript:>> 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.
