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.baden...@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/CAKSzg3RmMvEu1ponp5XZCUr%3D7AUnhPKE_h9J%3DXWEoLdtGJFKOw%40mail.gmail.com.
