FAQ
This is a relatively often used function in node.js. I think speeding it up
would be great. So I have an idea how to improve it.
What if we could set it every 1 ms to a variable, similar to how --prof
works.
This way we could get real time with 50-100 times less impact that it has
now.
So how stable --prof is? Is it really executed close to every ms, working
ok along with GC and so on?
What do you think about the idea? Any critics?

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Search Discussions

  • Ben Noordhuis at Oct 26, 2012 at 1:05 am

    On Thu, Oct 25, 2012 at 8:48 PM, Alexey Kupershtokh wrote:
    This is a relatively often used function in node.js. I think speeding it up
    would be great. So I have an idea how to improve it.
    What if we could set it every 1 ms to a variable, similar to how --prof
    works.
    This way we could get real time with 50-100 times less impact that it has
    now.
    So how stable --prof is? Is it really executed close to every ms, working ok
    along with GC and so on?
    What do you think about the idea? Any critics?
    I don't really care about speeding up Date.now() because it's already
    near optimal from a performance perspective. On Linux systems, it
    doesn't even require a system call, it simply reads the timestamp from
    the VDSO.

    Weeding out new Date() call sites is generally a good thing: the Date
    constructor is about 3x as slow as Date.now() and uses more memory to
    boot. I don't expect to see user-visible improvements outside of
    micro-benchmarks, though.

    Re: --prof, I don't quite see how it's connected to all this but yes,
    the profiler runs once every millisecond. It's a separate thread that
    wakes up at fixed intervals and records the main thread's instruction
    pointer (and some other bits).

    Actually, the profiler always runs, regardless of whether or not you
    specified --prof. It's what V8 uses to find out what code is hot.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 26, 2012 at 3:31 am
    Currently after removing one excessive call to Date.now makes the other
    Date.now call require as much time as all the other logic in setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove, L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about 1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec in simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were referring
    https://github.com/joyent/node/issues/4191 . How many Date.now() are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not optimal.

    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this 1ms is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.

    пятница, 26 октября 2012 г., 8:05:15 UTC+7 пользователь Ben Noordhuis
    написал:
    On Thu, Oct 25, 2012 at 8:48 PM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    This is a relatively often used function in node.js. I think speeding it up
    would be great. So I have an idea how to improve it.
    What if we could set it every 1 ms to a variable, similar to how --prof
    works.
    This way we could get real time with 50-100 times less impact that it has
    now.
    So how stable --prof is? Is it really executed close to every ms,
    working ok
    along with GC and so on?
    What do you think about the idea? Any critics?
    I don't really care about speeding up Date.now() because it's already
    near optimal from a performance perspective. On Linux systems, it
    doesn't even require a system call, it simply reads the timestamp from
    the VDSO.

    Weeding out new Date() call sites is generally a good thing: the Date
    constructor is about 3x as slow as Date.now() and uses more memory to
    boot. I don't expect to see user-visible improvements outside of
    micro-benchmarks, though.

    Re: --prof, I don't quite see how it's connected to all this but yes,
    the profiler runs once every millisecond. It's a separate thread that
    wakes up at fixed intervals and records the main thread's instruction
    pointer (and some other bits).

    Actually, the profiler always runs, regardless of whether or not you
    specified --prof. It's what V8 uses to find out what code is hot.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Ben Noordhuis at Oct 26, 2012 at 3:51 am

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh wrote:
    Currently after removing one excessive call to Date.now makes the other
    Date.now call require as much time as all the other logic in setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove, L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about 1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec in simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were referring
    https://github.com/joyent/node/issues/4191 . How many Date.now() are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not optimal.

    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this 1ms is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 26, 2012 at 8:33 am
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.js: 16402, 16735, 16783, 16815, 16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of speeding
    up Date.now().

    пятница, 26 октября 2012 г., 10:51:15 UTC+7 пользователь Ben Noordhuis
    написал:
    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now makes the other
    Date.now call require as much time as all the other logic in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove, L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about 1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec in simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were referring
    https://github.com/joyent/node/issues/4191 . How many Date.now() are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not optimal.

    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this 1ms is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Shigeki Ohtsu at Oct 26, 2012 at 10:38 am
    I disagree to re-implement Date.now() within Node because it is defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime() instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/node/compare/test_hrtime

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant difference
    as below.

    ./benchmark/http_simple_bench.sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


    ./benchmark/http_simple_bench.sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.js: 16402, 16735, 16783, 16815, 16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    пятница, 26 октября 2012 г., 10:51:15 UTC+7 пользователь Ben Noordhuis
    написал:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now makes the other
    Date.now call require as much time as all the other logic in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were referring
    https://github.com/joyent/node/issues/4191
    <https://github.com/joyent/node/issues/4191> . How many Date.now() are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not optimal.

    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this 1ms is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 26, 2012 at 10:46 am
    Ok, if re-implementing is not an option, then we could just add optimized
    version with different name. Or even write an external module. It doesn't
    matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki написал:
    I disagree to re-implement Date.now() within Node because it is defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime() instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/node/compare/test_hrtime

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant difference
    as below.

    ./benchmark/http_simple_bench.sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


    ./benchmark/http_simple_bench.sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.js: 16402, 16735, 16783, 16815, 16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫., 10:51:15
    UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ Ben Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now makes the other
    Date.now call require as much time as all the other logic in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were referring
    https://github.com/joyent/node/issues/4191
    <https://github.com/joyent/node/issues/4191> . How many Date.now()
    are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not optimal.

    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this 1ms is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com<javascript:>
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com <javascript:>
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Trevor Norris at Oct 27, 2012 at 1:59 am
    For .hrtime(), are you considering the fact that it's returning an Array,
    while Date.now() is returning an integer? v8 has some crazy optimizations
    for the later case. Also, are you considering how much time your actual
    loop costs or how many runs of Date.now() before incurring 10ms of
    performance hit?

    While there might be a better way, it's so fast already that there are much
    more important things on the map. Like TLS performance.

    Now, I'm not saying it's as fast as it could be. Take the following three
    cases:

    var len = 1e8,
    i = 0;
    while (++i <= len) { }

    output:

    real 0m0.287s
    user 0m0.280s
    sys 0m0.004s

    So I'm doing around 348,432,055/sec. Now the following:

    var len = 1e8,
    i = 0;
    while (++i <= len) {
    Math.random();
    }

    output:

    real 0m0.881s
    user 0m0.872s
    sys 0m0.012s

    So I'm doing around 125,000,000/sec. Now the final:

    var len = 1e8,
    i = 0;

    while (++i <= len) {
    Date.now();
    }

    output:

    real 0m4.183s
    user 0m4.176s
    sys 0m0.016s

    Which is around 23,906,287/sec.

    So yeah, there might be some performance improvements. But not enough to
    warrant a re-write of the method.

    trev
    On Friday, October 26, 2012 2:48:03 AM UTC-7, Alexey Kupershtokh wrote:

    Ok, if re-implementing is not an option, then we could just add optimized
    version with different name. Or even write an external module. It doesn't
    matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki написал:
    I disagree to re-implement Date.now() within Node because it is defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime() instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/node/compare/test_hrtime

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant difference
    as below.

    ./benchmark/http_simple_bench.sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


    ./benchmark/http_simple_bench.sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.js: 16402, 16735, 16783, 16815, 16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫., 10:51:15
    UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ Ben Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now makes
    the
    other
    Date.now call require as much time as all the other logic in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were
    referring
    are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not optimal.

    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this 1ms is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 27, 2012 at 4:17 am
    Trev, Looking at your numbers I totally agree with you.
    But I can't repeat these numbers and have the following9\:

    wicked@wnote:$ time node 1.js

    real 0m0.273s
    user 0m0.260s
    sys 0m0.016s
    wicked@wnote:~$ time node 2.js

    real 0m0.874s
    user 0m0.864s
    sys 0m0.012s
    wicked@wnote:~$ time node 3.js

    real 2m28.589s
    user 0m27.638s
    sys 2m2.340s

    It's 673,400/sec. Which is around 23,906,287/sec which is 35 times slower
    than your case :(

    In both node 0.8.14 taken from Chris Lee's debs and 0.9.2 compiled on my
    laptop.
    So the question transforms into "why is date.now so damn slow for me"

    суббота, 27 октября 2012 г., 7:10:51 UTC+7 пользователь Trevor Norris
    написал:
    For .hrtime(), are you considering the fact that it's returning an Array,
    while Date.now() is returning an integer? v8 has some crazy optimizations
    for the later case. Also, are you considering how much time your actual
    loop costs or how many runs of Date.now() before incurring 10ms of
    performance hit?

    While there might be a better way, it's so fast already that there are
    much more important things on the map. Like TLS performance.

    Now, I'm not saying it's as fast as it could be. Take the following three
    cases:

    var len = 1e8,
    i = 0;
    while (++i <= len) { }

    output:

    real 0m0.287s
    user 0m0.280s
    sys 0m0.004s

    So I'm doing around 348,432,055/sec. Now the following:

    var len = 1e8,
    i = 0;
    while (++i <= len) {
    Math.random();
    }

    output:

    real 0m0.881s
    user 0m0.872s
    sys 0m0.012s

    So I'm doing around 125,000,000/sec. Now the final:

    var len = 1e8,
    i = 0;

    while (++i <= len) {
    Date.now();
    }

    output:

    real 0m4.183s
    user 0m4.176s
    sys 0m0.016s

    So yeah, there might be some performance improvements. But not enough to
    warrant a re-write of the method.

    trev
    On Friday, October 26, 2012 2:48:03 AM UTC-7, Alexey Kupershtokh wrote:

    Ok, if re-implementing is not an option, then we could just add optimized
    version with different name. Or even write an external module. It doesn't
    matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki написал:
    I disagree to re-implement Date.now() within Node because it is defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime() instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/node/compare/test_hrtime

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant difference
    as below.

    ./benchmark/http_simple_bench.sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


    ./benchmark/http_simple_bench.sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.js: 16402, 16735, 16783, 16815, 16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫., 10:51:15
    UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ Ben Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now makes
    the
    other
    Date.now call require as much time as all the other logic in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were
    referring
    Date.now() are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not optimal.

    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this 1ms is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Niknah at Oct 27, 2012 at 5:26 pm
    It's pretty quick for me. I noticed that your timing is 27secs for user,
    and 2 minutes for system. When you run it, is there any CPU usage?

    Try this on google chrome & some other browser to see if it's a node, v8 or
    computer related problem...

    http://jsperf.com/new-date-value/9



    On Saturday, October 27, 2012 1:31:17 PM UTC+11, Alexey Kupershtokh wrote:

    Trev, Looking at your numbers I totally agree with you.
    But I can't repeat these numbers and have the following9\:

    wicked@wnote:$ time node 1.js

    real 0m0.273s
    user 0m0.260s
    sys 0m0.016s
    wicked@wnote:~$ time node 2.js

    real 0m0.874s
    user 0m0.864s
    sys 0m0.012s
    wicked@wnote:~$ time node 3.js

    real 2m28.589s
    user 0m27.638s
    sys 2m2.340s

    It's 673,400/sec. Which is around 23,906,287/sec which is 35 times slower
    than your case :(

    In both node 0.8.14 taken from Chris Lee's debs and 0.9.2 compiled on my
    laptop.
    So the question transforms into "why is date.now so damn slow for me"

    суббота, 27 октября 2012 г., 7:10:51 UTC+7 пользователь Trevor Norris
    написал:
    For .hrtime(), are you considering the fact that it's returning an Array,
    while Date.now() is returning an integer? v8 has some crazy optimizations
    for the later case. Also, are you considering how much time your actual
    loop costs or how many runs of Date.now() before incurring 10ms of
    performance hit?

    While there might be a better way, it's so fast already that there are
    much more important things on the map. Like TLS performance.

    Now, I'm not saying it's as fast as it could be. Take the following three
    cases:

    var len = 1e8,
    i = 0;
    while (++i <= len) { }

    output:

    real 0m0.287s
    user 0m0.280s
    sys 0m0.004s

    So I'm doing around 348,432,055/sec. Now the following:

    var len = 1e8,
    i = 0;
    while (++i <= len) {
    Math.random();
    }

    output:

    real 0m0.881s
    user 0m0.872s
    sys 0m0.012s

    So I'm doing around 125,000,000/sec. Now the final:

    var len = 1e8,
    i = 0;

    while (++i <= len) {
    Date.now();
    }

    output:

    real 0m4.183s
    user 0m4.176s
    sys 0m0.016s

    So yeah, there might be some performance improvements. But not enough to
    warrant a re-write of the method.

    trev
    On Friday, October 26, 2012 2:48:03 AM UTC-7, Alexey Kupershtokh wrote:

    Ok, if re-implementing is not an option, then we could just add
    optimized version with different name. Or even write an external module. It
    doesn't matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki написал:
    I disagree to re-implement Date.now() within Node because it is defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime() instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/node/compare/test_hrtime

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant difference
    as below.

    ./benchmark/http_simple_bench.sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


    ./benchmark/http_simple_bench.sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.js: 16402, 16735, 16783, 16815, 16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫., 10:51:15
    UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ Ben Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now makes
    the
    other
    Date.now call require as much time as all the other logic in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec
    in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were
    referring
    Date.now() are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not
    optimal.
    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this
    1ms
    is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 27, 2012 at 7:21 pm
    Cpu usage of other proceses is about 3-5%. When node 3.js was running top
    showed:

    Cpu(s): 13.8%us, 41.6%sy, 0.0%ni, 43.6%id, 1.0%wa, 0.0%hi, 0.0%si,
    0.0%st

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


    12672 wicked 20 0 35192 9104 4204 R 101 0.1 0:42.00 node


    17368 wicked 20 0 275m 86m 23m S 2 1.4 5:09.69 chrome
    ...

    You can find the "Chrome 23.0.1271 (1)" on
    http://jsperf.com/new-date-value/9 which is much slower than others.
    Date.now() is 583,442 only. Very interesting results.
    So I must conclude it's not only node-related but the overall v8's Date.now
    is affected.

    wicked@wnote:~$ cat /etc/issue
    Ubuntu 12.04.1 LTS \n \l

    wicked@wnote:~$ uname -a
    Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC
    2012 i686 i686 i386 GNU/Linux



    воскресенье, 28 октября 2012 г., 0:26:10 UTC+7 пользователь niknah написал:
    It's pretty quick for me. I noticed that your timing is 27secs for user,
    and 2 minutes for system. When you run it, is there any CPU usage?

    Try this on google chrome & some other browser to see if it's a node, v8
    or computer related problem...

    http://jsperf.com/new-date-value/9



    On Saturday, October 27, 2012 1:31:17 PM UTC+11, Alexey Kupershtokh wrote:

    Trev, Looking at your numbers I totally agree with you.
    But I can't repeat these numbers and have the following9\:

    wicked@wnote:$ time node 1.js

    real 0m0.273s
    user 0m0.260s
    sys 0m0.016s
    wicked@wnote:~$ time node 2.js

    real 0m0.874s
    user 0m0.864s
    sys 0m0.012s
    wicked@wnote:~$ time node 3.js

    real 2m28.589s
    user 0m27.638s
    sys 2m2.340s

    It's 673,400/sec. Which is around 23,906,287/sec which is 35 times slower
    than your case :(

    In both node 0.8.14 taken from Chris Lee's debs and 0.9.2 compiled on my
    laptop.
    So the question transforms into "why is date.now so damn slow for me"

    суббота, 27 октября 2012 г., 7:10:51 UTC+7 пользователь Trevor Norris
    написал:
    For .hrtime(), are you considering the fact that it's returning an
    Array, while Date.now() is returning an integer? v8 has some crazy
    optimizations for the later case. Also, are you considering how much time
    your actual loop costs or how many runs of Date.now() before incurring 10ms
    of performance hit?

    While there might be a better way, it's so fast already that there are
    much more important things on the map. Like TLS performance.

    Now, I'm not saying it's as fast as it could be. Take the following
    three cases:

    var len = 1e8,
    i = 0;
    while (++i <= len) { }

    output:

    real 0m0.287s
    user 0m0.280s
    sys 0m0.004s

    So I'm doing around 348,432,055/sec. Now the following:

    var len = 1e8,
    i = 0;
    while (++i <= len) {
    Math.random();
    }

    output:

    real 0m0.881s
    user 0m0.872s
    sys 0m0.012s

    So I'm doing around 125,000,000/sec. Now the final:

    var len = 1e8,
    i = 0;

    while (++i <= len) {
    Date.now();
    }

    output:

    real 0m4.183s
    user 0m4.176s
    sys 0m0.016s

    So yeah, there might be some performance improvements. But not enough to
    warrant a re-write of the method.

    trev
    On Friday, October 26, 2012 2:48:03 AM UTC-7, Alexey Kupershtokh wrote:

    Ok, if re-implementing is not an option, then we could just add
    optimized version with different name. Or even write an external module. It
    doesn't matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki
    написал:
    I disagree to re-implement Date.now() within Node because it is
    defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime() instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/node/compare/test_hrtime

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant
    difference
    as below.

    ./benchmark/http_simple_bench.sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


    ./benchmark/http_simple_bench.sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.js: 16402, 16735, 16783, 16815, 16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫., 10:51:15
    UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ Ben Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now makes
    the
    other
    Date.now call require as much time as all the other logic in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec
    in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were
    referring
    Date.now() are
    performed for each request? Let's say this number is 1. Let's calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not
    optimal.
    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this
    1ms
    is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 27, 2012 at 6:30 pm
    Testing in Firefox 16.0 on Ubuntu
    Date.now() is 713,232 /s
    Seems it's even system-wide. How to fix this?
    On Sun, Oct 28, 2012 at 1:21 AM, Alexey Kupershtokh wrote:

    Cpu usage of other proceses is about 3-5%. When node 3.js was running top
    showed:

    Cpu(s): 13.8%us, 41.6%sy, 0.0%ni, 43.6%id, 1.0%wa, 0.0%hi, 0.0%si,
    0.0%st

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


    12672 wicked 20 0 35192 9104 4204 R 101 0.1 0:42.00 node


    17368 wicked 20 0 275m 86m 23m S 2 1.4 5:09.69 chrome
    ...

    You can find the "Chrome 23.0.1271 (1)" on http://jsperf.com/new-date-**
    value/9 <http://jsperf.com/new-date-value/9> which is much slower than
    others.
    Date.now() is 583,442 only. Very interesting results.
    So I must conclude it's not only node-related but the overall v8's
    Date.now is affected.

    wicked@wnote:~$ cat /etc/issue
    Ubuntu 12.04.1 LTS \n \l

    wicked@wnote:~$ uname -a
    Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC
    2012 i686 i686 i386 GNU/Linux



    воскресенье, 28 октября 2012 г., 0:26:10 UTC+7 пользователь niknah написал:
    It's pretty quick for me. I noticed that your timing is 27secs for user,
    and 2 minutes for system. When you run it, is there any CPU usage?

    Try this on google chrome & some other browser to see if it's a node, v8
    or computer related problem...

    http://jsperf.com/new-date-**value/9 <http://jsperf.com/new-date-value/9>



    On Saturday, October 27, 2012 1:31:17 PM UTC+11, Alexey Kupershtokh wrote:

    Trev, Looking at your numbers I totally agree with you.
    But I can't repeat these numbers and have the following9\:

    wicked@wnote:$ time node 1.js

    real 0m0.273s
    user 0m0.260s
    sys 0m0.016s
    wicked@wnote:~$ time node 2.js

    real 0m0.874s
    user 0m0.864s
    sys 0m0.012s
    wicked@wnote:~$ time node 3.js

    real 2m28.589s
    user 0m27.638s
    sys 2m2.340s

    It's 673,400/sec. Which is around 23,906,287/sec which is 35 times
    slower than your case :(

    In both node 0.8.14 taken from Chris Lee's debs and 0.9.2 compiled on my
    laptop.
    So the question transforms into "why is date.now so damn slow for me"

    суббота, 27 октября 2012 г., 7:10:51 UTC+7 пользователь Trevor Norris
    написал:
    For .hrtime(), are you considering the fact that it's returning an
    Array, while Date.now() is returning an integer? v8 has some crazy
    optimizations for the later case. Also, are you considering how much time
    your actual loop costs or how many runs of Date.now() before incurring 10ms
    of performance hit?

    While there might be a better way, it's so fast already that there are
    much more important things on the map. Like TLS performance.

    Now, I'm not saying it's as fast as it could be. Take the following
    three cases:

    var len = 1e8,
    i = 0;
    while (++i <= len) { }

    output:

    real 0m0.287s
    user 0m0.280s
    sys 0m0.004s

    So I'm doing around 348,432,055/sec. Now the following:

    var len = 1e8,
    i = 0;
    while (++i <= len) {
    Math.random();
    }

    output:

    real 0m0.881s
    user 0m0.872s
    sys 0m0.012s

    So I'm doing around 125,000,000/sec. Now the final:

    var len = 1e8,
    i = 0;

    while (++i <= len) {
    Date.now();
    }

    output:

    real 0m4.183s
    user 0m4.176s
    sys 0m0.016s

    So yeah, there might be some performance improvements. But not enough
    to warrant a re-write of the method.

    trev
    On Friday, October 26, 2012 2:48:03 AM UTC-7, Alexey Kupershtokh wrote:

    Ok, if re-implementing is not an option, then we could just add
    optimized version with different name. Or even write an external module. It
    doesn't matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki
    написал:
    I disagree to re-implement Date.now() within Node because it is
    defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime()
    instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/**node/compare/test_hrtime<https://github.com/shigeki/node/compare/test_hrtime>

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant
    difference
    as below.

    ./benchmark/http_simple_bench.**sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


    ./benchmark/http_simple_bench.**sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.**js: 16402, 16735, 16783, 16815,
    16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫., 10:51:15
    UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫**О©╫О©╫ Ben Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now
    makes the
    other
    Date.now call require as much time as all the other logic in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated
    about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M ops/sec
    in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were
    referring
    . How many Date.now() are
    performed for each request? Let's say this number is 1.
    Let's
    calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not
    optimal.
    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this
    1ms
    is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume - benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/**node/wiki/Mailing-List-**
    Posting-Guidelines<https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines>
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en>
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 27, 2012 at 6:42 pm
    PS: My CPU is Intel® Core™ 2 Duo P7350(2GHz, 1 066MHz, 3Mb).

    воскресенье, 28 октября 2012 г., 1:30:35 UTC+7 пользователь Alexey
    Kupershtokh написал:
    Testing in Firefox 16.0 on Ubuntu
    Date.now() is 713,232 /s
    Seems it's even system-wide. How to fix this?

    On Sun, Oct 28, 2012 at 1:21 AM, Alexey Kupershtokh <
    alexey.kupershtokh@gmail.com> wrote:
    Cpu usage of other proceses is about 3-5%. When node 3.js was running top
    showed:

    Cpu(s): 13.8%us, 41.6%sy, 0.0%ni, 43.6%id, 1.0%wa, 0.0%hi, 0.0%si,
    0.0%st

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


    12672 wicked 20 0 35192 9104 4204 R 101 0.1 0:42.00 node


    17368 wicked 20 0 275m 86m 23m S 2 1.4 5:09.69 chrome
    ...

    You can find the "Chrome 23.0.1271 (1)" on http://jsperf.com/new-date-**
    value/9 <http://jsperf.com/new-date-value/9> which is much slower than
    others.
    Date.now() is 583,442 only. Very interesting results.
    So I must conclude it's not only node-related but the overall v8's
    Date.now is affected.

    wicked@wnote:~$ cat /etc/issue
    Ubuntu 12.04.1 LTS \n \l

    wicked@wnote:~$ uname -a
    Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC
    2012 i686 i686 i386 GNU/Linux



    воскресенье, 28 октября 2012 г., 0:26:10 UTC+7 пользователь niknah
    написал:
    It's pretty quick for me. I noticed that your timing is 27secs for
    user, and 2 minutes for system. When you run it, is there any CPU usage?

    Try this on google chrome & some other browser to see if it's a node, v8
    or computer related problem...

    http://jsperf.com/new-date-**value/9<http://jsperf.com/new-date-value/9>




    On Saturday, October 27, 2012 1:31:17 PM UTC+11, Alexey Kupershtokh
    wrote:
    Trev, Looking at your numbers I totally agree with you.
    But I can't repeat these numbers and have the following9\:

    wicked@wnote:$ time node 1.js

    real 0m0.273s
    user 0m0.260s
    sys 0m0.016s
    wicked@wnote:~$ time node 2.js

    real 0m0.874s
    user 0m0.864s
    sys 0m0.012s
    wicked@wnote:~$ time node 3.js

    real 2m28.589s
    user 0m27.638s
    sys 2m2.340s

    It's 673,400/sec. Which is around 23,906,287/sec which is 35 times
    slower than your case :(

    In both node 0.8.14 taken from Chris Lee's debs and 0.9.2 compiled on
    my laptop.
    So the question transforms into "why is date.now so damn slow for me"

    суббота, 27 октября 2012 г., 7:10:51 UTC+7 пользователь Trevor Norris
    написал:
    For .hrtime(), are you considering the fact that it's returning an
    Array, while Date.now() is returning an integer? v8 has some crazy
    optimizations for the later case. Also, are you considering how much time
    your actual loop costs or how many runs of Date.now() before incurring 10ms
    of performance hit?

    While there might be a better way, it's so fast already that there are
    much more important things on the map. Like TLS performance.

    Now, I'm not saying it's as fast as it could be. Take the following
    three cases:

    var len = 1e8,
    i = 0;
    while (++i <= len) { }

    output:

    real 0m0.287s
    user 0m0.280s
    sys 0m0.004s

    So I'm doing around 348,432,055/sec. Now the following:

    var len = 1e8,
    i = 0;
    while (++i <= len) {
    Math.random();
    }

    output:

    real 0m0.881s
    user 0m0.872s
    sys 0m0.012s

    So I'm doing around 125,000,000/sec. Now the final:

    var len = 1e8,
    i = 0;

    while (++i <= len) {
    Date.now();
    }

    output:

    real 0m4.183s
    user 0m4.176s
    sys 0m0.016s

    So yeah, there might be some performance improvements. But not enough
    to warrant a re-write of the method.

    trev
    On Friday, October 26, 2012 2:48:03 AM UTC-7, Alexey Kupershtokh wrote:

    Ok, if re-implementing is not an option, then we could just add
    optimized version with different name. Or even write an external module. It
    doesn't matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki
    написал:
    I disagree to re-implement Date.now() within Node because it is
    defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime()
    instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/**node/compare/test_hrtime<https://github.com/shigeki/node/compare/test_hrtime>

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant
    difference
    as below.

    ./benchmark/http_simple_bench.**sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29 [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99 [#/sec]


    ./benchmark/http_simple_bench.**sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16 [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89 [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58 [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.**js: 16402, 16735, 16783, 16815,
    16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫.,
    10:51:15 UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫**О©╫О©╫ Ben Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now
    makes the
    other
    Date.now call require as much time as all the other logic
    in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated
    about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M
    ops/sec in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were
    referring
    . How many Date.now() are
    performed for each request? Let's say this number is 1.
    Let's
    calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not
    optimal.
    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during this
    1ms
    is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume -
    benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/**node/wiki/Mailing-List-**
    Posting-Guidelines<https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines>
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en>
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 27, 2012 at 7:44 pm
    Do I understand correctly that this code is responsible for Date.now() ?
    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/date.js#L312
    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/runtime.cc#L9239

    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-nullos.cc#L108
    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-posix.cc#L170
    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-win32.cc#L586

    воскресенье, 28 октября 2012 г., 1:36:45 UTC+7 пользователь Alexey
    Kupershtokh написал:
    PS: My CPU is Intel® Core™ 2 Duo P7350(2GHz, 1 066MHz, 3Mb).

    воскресенье, 28 октября 2012 г., 1:30:35 UTC+7 пользователь Alexey
    Kupershtokh написал:
    Testing in Firefox 16.0 on Ubuntu
    Date.now() is 713,232 /s
    Seems it's even system-wide. How to fix this?

    On Sun, Oct 28, 2012 at 1:21 AM, Alexey Kupershtokh <
    alexey.kupershtokh@gmail.com> wrote:
    Cpu usage of other proceses is about 3-5%. When node 3.js was running
    top showed:

    Cpu(s): 13.8%us, 41.6%sy, 0.0%ni, 43.6%id, 1.0%wa, 0.0%hi, 0.0%si,
    0.0%st

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


    12672 wicked 20 0 35192 9104 4204 R 101 0.1 0:42.00 node


    17368 wicked 20 0 275m 86m 23m S 2 1.4 5:09.69 chrome
    ...

    You can find the "Chrome 23.0.1271 (1)" on http://jsperf.com/new-date-**
    value/9 <http://jsperf.com/new-date-value/9> which is much slower than
    others.
    Date.now() is 583,442 only. Very interesting results.
    So I must conclude it's not only node-related but the overall v8's
    Date.now is affected.

    wicked@wnote:~$ cat /etc/issue
    Ubuntu 12.04.1 LTS \n \l

    wicked@wnote:~$ uname -a
    Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC
    2012 i686 i686 i386 GNU/Linux



    воскресенье, 28 октября 2012 г., 0:26:10 UTC+7 пользователь niknah
    написал:
    It's pretty quick for me. I noticed that your timing is 27secs for
    user, and 2 minutes for system. When you run it, is there any CPU usage?

    Try this on google chrome & some other browser to see if it's a node,
    v8 or computer related problem...

    http://jsperf.com/new-date-**value/9<http://jsperf.com/new-date-value/9>




    On Saturday, October 27, 2012 1:31:17 PM UTC+11, Alexey Kupershtokh
    wrote:
    Trev, Looking at your numbers I totally agree with you.
    But I can't repeat these numbers and have the following9\:

    wicked@wnote:$ time node 1.js

    real 0m0.273s
    user 0m0.260s
    sys 0m0.016s
    wicked@wnote:~$ time node 2.js

    real 0m0.874s
    user 0m0.864s
    sys 0m0.012s
    wicked@wnote:~$ time node 3.js

    real 2m28.589s
    user 0m27.638s
    sys 2m2.340s

    It's 673,400/sec. Which is around 23,906,287/sec which is 35 times
    slower than your case :(

    In both node 0.8.14 taken from Chris Lee's debs and 0.9.2 compiled on
    my laptop.
    So the question transforms into "why is date.now so damn slow for me"

    суббота, 27 октября 2012 г., 7:10:51 UTC+7 пользователь Trevor Norris
    написал:
    For .hrtime(), are you considering the fact that it's returning an
    Array, while Date.now() is returning an integer? v8 has some crazy
    optimizations for the later case. Also, are you considering how much time
    your actual loop costs or how many runs of Date.now() before incurring 10ms
    of performance hit?

    While there might be a better way, it's so fast already that there
    are much more important things on the map. Like TLS performance.

    Now, I'm not saying it's as fast as it could be. Take the following
    three cases:

    var len = 1e8,
    i = 0;
    while (++i <= len) { }

    output:

    real 0m0.287s
    user 0m0.280s
    sys 0m0.004s

    So I'm doing around 348,432,055/sec. Now the following:

    var len = 1e8,
    i = 0;
    while (++i <= len) {
    Math.random();
    }

    output:

    real 0m0.881s
    user 0m0.872s
    sys 0m0.012s

    So I'm doing around 125,000,000/sec. Now the final:

    var len = 1e8,
    i = 0;

    while (++i <= len) {
    Date.now();
    }

    output:

    real 0m4.183s
    user 0m4.176s
    sys 0m0.016s

    So yeah, there might be some performance improvements. But not enough
    to warrant a re-write of the method.

    trev

    On Friday, October 26, 2012 2:48:03 AM UTC-7, Alexey Kupershtokh
    wrote:
    Ok, if re-implementing is not an option, then we could just add
    optimized version with different name. Or even write an external module. It
    doesn't matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki
    написал:
    I disagree to re-implement Date.now() within Node because it is
    defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime()
    instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/**node/compare/test_hrtime<https://github.com/shigeki/node/compare/test_hrtime>

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant
    difference
    as below.

    ./benchmark/http_simple_bench.**sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97
    [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29
    [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99
    [#/sec]


    ./benchmark/http_simple_bench.**sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16
    [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89
    [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75 [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58
    [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076, 16091; avg
    = 15913
    benchmark/http_simple_auto2.**js: 16402, 16735, 16783, 16815,
    16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫.,
    10:51:15 UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫**О©╫О©╫ Ben
    Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now
    makes the
    other
    Date.now call require as much time as all the other logic
    in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated
    about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M
    ops/sec in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were
    referring
    . How many Date.now() are
    performed for each request? Let's say this number is 1.
    Let's
    calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not
    optimal.
    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during
    this 1ms
    is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume -
    benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/**node/wiki/Mailing-List-**
    Posting-Guidelines<https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines>
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en>
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 28, 2012 at 3:17 am
    Testing in Chrome 22.0.1229.94 on Windows Vista:

    Using .valueOf() | new Date().valueOf(); | 3,041,709±0.52% | 57% slower
    Using .getTime() | new Date().getTime(); | 3,123,610±0.40% | 55% slower
    Using +new Date() | +new Date(); |1,945,890±5.94% | 74% slower
    Using +new Date | +new Date; |2,050,588±3.42% | 72% slower
    Date.now() | Date.now(); | 7,010,134±0.51% | fastest
    Date.now() | dereferenceddatenow(); | 6,995,289±0.81% | fastest

    Node.js 0.8.14 installed from official msi:
    D:\work\node>node 1.js
    Finished in 205 ms, 487,804,878 ops/sec

    D:\work\node>node 2.js
    Finished in 899 ms, 111,234,705 ops/sec

    D:\work\node>node 3.js
    Finished in 14412 ms, 6,938,662 ops/sec

    It's 10 times faster than in ubuntu.
    I have 2 very different:
    1) laptop with ubuntu 12.04 x86 with PAE & windows vista
    1) PC with ubuntu 11.04 x86 with PAE
    (PAE is https://help.ubuntu.com/community/EnablingPAE )

    So there's a problem with Date.now() in node, chrome and firefox in both
    ubuntus.

    воскресенье, 28 октября 2012 г., 2:44:05 UTC+7 пользователь Alexey
    Kupershtokh написал:
    Do I understand correctly that this code is responsible for Date.now() ?
    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/date.js#L312
    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/runtime.cc#L9239


    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-nullos.cc#L108

    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-posix.cc#L170

    https://github.com/joyent/node/blob/v0.9.2/deps/v8/src/platform-win32.cc#L586

    воскресенье, 28 октября 2012 г., 1:36:45 UTC+7 пользователь Alexey
    Kupershtokh написал:
    PS: My CPU is Intel® Core™ 2 Duo P7350(2GHz, 1 066MHz, 3Mb).

    воскресенье, 28 октября 2012 г., 1:30:35 UTC+7 пользователь Alexey
    Kupershtokh написал:
    Testing in Firefox 16.0 on Ubuntu
    Date.now() is 713,232 /s
    Seems it's even system-wide. How to fix this?

    On Sun, Oct 28, 2012 at 1:21 AM, Alexey Kupershtokh <
    alexey.kupershtokh@gmail.com> wrote:
    Cpu usage of other proceses is about 3-5%. When node 3.js was running
    top showed:

    Cpu(s): 13.8%us, 41.6%sy, 0.0%ni, 43.6%id, 1.0%wa, 0.0%hi, 0.0%si,
    0.0%st

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND


    12672 wicked 20 0 35192 9104 4204 R 101 0.1 0:42.00 node


    17368 wicked 20 0 275m 86m 23m S 2 1.4 5:09.69 chrome
    ...

    You can find the "Chrome 23.0.1271 (1)" on http://jsperf.com/new-date-*
    *value/9 <http://jsperf.com/new-date-value/9> which is much slower
    than others.
    Date.now() is 583,442 only. Very interesting results.
    So I must conclude it's not only node-related but the overall v8's
    Date.now is affected.

    wicked@wnote:~$ cat /etc/issue
    Ubuntu 12.04.1 LTS \n \l

    wicked@wnote:~$ uname -a
    Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC
    2012 i686 i686 i386 GNU/Linux



    воскресенье, 28 октября 2012 г., 0:26:10 UTC+7 пользователь niknah
    написал:
    It's pretty quick for me. I noticed that your timing is 27secs for
    user, and 2 minutes for system. When you run it, is there any CPU usage?

    Try this on google chrome & some other browser to see if it's a node,
    v8 or computer related problem...

    http://jsperf.com/new-date-**value/9<http://jsperf.com/new-date-value/9>




    On Saturday, October 27, 2012 1:31:17 PM UTC+11, Alexey Kupershtokh
    wrote:
    Trev, Looking at your numbers I totally agree with you.
    But I can't repeat these numbers and have the following9\:

    wicked@wnote:$ time node 1.js

    real 0m0.273s
    user 0m0.260s
    sys 0m0.016s
    wicked@wnote:~$ time node 2.js

    real 0m0.874s
    user 0m0.864s
    sys 0m0.012s
    wicked@wnote:~$ time node 3.js

    real 2m28.589s
    user 0m27.638s
    sys 2m2.340s

    It's 673,400/sec. Which is around 23,906,287/sec which is 35 times
    slower than your case :(

    In both node 0.8.14 taken from Chris Lee's debs and 0.9.2 compiled on
    my laptop.
    So the question transforms into "why is date.now so damn slow for me"

    суббота, 27 октября 2012 г., 7:10:51 UTC+7 пользователь Trevor Norris
    написал:
    For .hrtime(), are you considering the fact that it's returning an
    Array, while Date.now() is returning an integer? v8 has some crazy
    optimizations for the later case. Also, are you considering how much time
    your actual loop costs or how many runs of Date.now() before incurring 10ms
    of performance hit?

    While there might be a better way, it's so fast already that there
    are much more important things on the map. Like TLS performance.

    Now, I'm not saying it's as fast as it could be. Take the following
    three cases:

    var len = 1e8,
    i = 0;
    while (++i <= len) { }

    output:

    real 0m0.287s
    user 0m0.280s
    sys 0m0.004s

    So I'm doing around 348,432,055/sec. Now the following:

    var len = 1e8,
    i = 0;
    while (++i <= len) {
    Math.random();
    }

    output:

    real 0m0.881s
    user 0m0.872s
    sys 0m0.012s

    So I'm doing around 125,000,000/sec. Now the final:

    var len = 1e8,
    i = 0;

    while (++i <= len) {
    Date.now();
    }

    output:

    real 0m4.183s
    user 0m4.176s
    sys 0m0.016s

    So yeah, there might be some performance improvements. But not
    enough to warrant a re-write of the method.

    trev

    On Friday, October 26, 2012 2:48:03 AM UTC-7, Alexey Kupershtokh
    wrote:
    Ok, if re-implementing is not an option, then we could just add
    optimized version with different name. Or even write an external module. It
    doesn't matter.

    And process.hrtime() is even slower than Date.now();

    +new Date x 1,106,626 ops/sec ±0.80% (99 runs sampled)
    Date.now() x 1,418,551 ops/sec ±0.16% (101 runs sampled)
    process.hrtime() x 833,820 ops/sec ±0.16% (101 runs sampled)
    microtime.now() x 1,247,487 ops/sec ±1.03% (100 runs sampled)


    пятница, 26 октября 2012 г., 16:39:14 UTC+7 пользователь shigeki
    написал:
    I disagree to re-implement Date.now() within Node because it is
    defined
    in ES5 and V8 should take care of its performance.

    In timer case, there is an alternative to use process.hrtime()
    instead
    of Date.now(). I've just made a quick hack to use it in

    https://github.com/shigeki/**node/compare/test_hrtime<https://github.com/shigeki/node/compare/test_hrtime>

    for benchmark.

    I tested http_simple_bench.sh but there seems no significant
    difference
    as below.

    ./benchmark/http_simple_bench.**sh with Date.now() in timer
    ab-hello-world-buffer-102400 Requests per second: 1548.97
    [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1755.29
    [#/sec]
    ab-hello-world-string-102400 Requests per second: 459.39
    [#/sec]
    ab-hello-world-string-1024 Requests per second: 1919.99
    [#/sec]


    ./benchmark/http_simple_bench.**sh with process.hrtime() in timer
    ab-hello-world-buffer-102400 Requests per second: 1491.16
    [#/sec]
    ab-hello-world-buffer-1024 Requests per second: 1748.89
    [#/sec]
    ab-hello-world-string-102400 Requests per second: 612.75
    [#/sec]
    ab-hello-world-string-1024 Requests per second: 1953.58
    [#/sec]

    (2012/10/26 16:38), Alexey Kupershtokh wrote:
    Ok then.

    cp benchmark/http_simple_auto.js benchmark/http_simple_auto2.js
    edit benchmark/http_simple_auto2.js and add this code at the start:
    var n = 1000;
    var now = Date.now();
    Date.now = function() {
    if (n-- == 0) {
    n = 1000;
    now = Date.now();
    }
    return now;
    }

    Make sure you have a version that already uses Date.now() in timers.js
    instead of new Date();

    RPS for the benchmarks in a few runs in turn, sorted by asc:
    benchmark/http_simple_auto.js: 15635, 15739, 16025, 16076,
    16091; avg
    = 15913
    benchmark/http_simple_auto2.**js: 16402, 16735, 16783, 16815,
    16881; avg
    = 16723
    16723 / 15913 = 1.051
    So the http_simple_auto2.js is overall 5% faster just because of
    speeding up Date.now().

    О©╫О©╫О©╫О©╫О©╫О©╫О©╫, 26 О©╫О©╫О©╫О©╫О©╫О©╫О©╫ 2012 О©╫.,
    10:51:15 UTC+7 О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫**О©╫О©╫ Ben
    Noordhuis
    О©╫О©╫О©╫О©╫О©╫О©╫О©╫:

    On Fri, Oct 26, 2012 at 5:31 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    Currently after removing one excessive call to Date.now
    makes the
    other
    Date.now call require as much time as all the other logic
    in
    setTimeout() +
    active() + all the _linklist stuff (L.isempty, L.remove,
    L.append, etc.). I
    think it can be better.

    Looking from another side, Date.now() can be calculated
    about
    1.4M ops/sec
    rate on my pc. But EventEmitter can perform at 5-20M
    ops/sec in
    simple emit
    scenarios.

    Ok, let's take into account an http benchmark, you were
    referring
    . How many Date.now() are
    performed for each request? Let's say this number is 1.
    Let's
    calculate
    Date.now cpu usage: 21K/1.4M is 1.5% spent only on time
    calculation. Is it
    that much to optimize? I don't actually know.

    So I would say, that Date.now() is fast enough but not
    optimal.
    Regarding the --perf, let me show the concept:
    var ts = null;
    Date.now = function() {
    if (!ts) return ts = gettimeofday(2);
    return ts;
    };
    Thread that ticks every millisecond, similar to
    profiler's
    thread, just
    flushes the cache:
    {
    ts = null;
    }

    This way Date.now is cached ad most for 1ms and during
    this 1ms
    is always
    returned from the variable.
    new Date() could be then behave like new Date(ts);

    That's it.
    When it comes to performance, don't guess or assume -
    benchmark it.
    Clone the repo, try out your changes and see what difference it makes
    on benchmark/http_simple or benchmark/http_simple_auto.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/**node/wiki/Mailing-List-**
    Posting-Guidelines<https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines>
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nod...@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+un...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/**group/nodejs?hl=en?hl=en<http://groups.google.com/group/nodejs?hl=en?hl=en>
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 29, 2012 at 5:23 am
    I've found an extreme solution:

    I upgraded ubuntu from
    Ubuntu 12.04.1 LTS \n \l;
    Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC
    2012 i686 i686 i386 GNU/Linux
    to
    Ubuntu 12.10 \n \l;
    Linux wnote 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
    x86_64 x86_64 x86_64 GNU/Linux

    And performance increased 15-20 times to these numbers:


    1. Chrome 22: 10,946,261
    2. FF 16: 15,301,293
    3. Node 0.8.14: 11,671,335


    Differences are:
    ubuntu: 12.04 -> 12.10
    kernel: 3.2.0-33 -> 3.5.0-17
    arch: i686 + pae (32 bit) -> x86_64 (64 bit)

    I don't know which one matters, but it's a subject for further
    investigation.

    пятница, 26 октября 2012 г., 1:48:50 UTC+7 пользователь Alexey Kupershtokh
    написал:
    This is a relatively often used function in node.js. I think speeding it
    up would be great. So I have an idea how to improve it.
    What if we could set it every 1 ms to a variable, similar to how --prof
    works.
    This way we could get real time with 50-100 times less impact that it has
    now.
    So how stable --prof is? Is it really executed close to every ms, working
    ok along with GC and so on?
    What do you think about the idea? Any critics?
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Ben Noordhuis at Oct 29, 2012 at 12:38 pm

    On Mon, Oct 29, 2012 at 6:15 AM, Alexey Kupershtokh wrote:
    I've found an extreme solution:

    I upgraded ubuntu from
    Ubuntu 12.04.1 LTS \n \l;
    Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC 2012
    i686 i686 i386 GNU/Linux
    to
    Ubuntu 12.10 \n \l;
    Linux wnote 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
    x86_64 x86_64 x86_64 GNU/Linux

    And performance increased 15-20 times to these numbers:

    Chrome 22: 10,946,261
    FF 16: 15,301,293
    Node 0.8.14: 11,671,335


    Differences are:
    ubuntu: 12.04 -> 12.10
    kernel: 3.2.0-33 -> 3.5.0-17
    arch: i686 + pae (32 bit) -> x86_64 (64 bit)

    I don't know which one matters, but it's a subject for further
    investigation.
    It's probably glibc/VDSO changes. I wager that when you trace your
    benchmark with `strace -c gettimeofday,clock_gettime`, you'll see a
    ton of hits on your old system and hardly any on your new system.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Kupershtokh at Oct 29, 2012 at 3:44 pm
    Did you mean command strace -c -e "gettimeofday,clock_gettime" node 3.js ?

    Old (on a more powerful desktop pc):
    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

    13220 wicked 20 0 2104 508 428 S 66 0.0 7:46.70 strace

    13221 wicked 20 0 33144 9036 4136 R 41 0.1 4:42.47 node


    wicked@wicked-desktop:~/Alawar$ time strace -c -e
    "gettimeofday,clock_gettime" node 3.js
    ^C% time seconds usecs/call calls errors syscall
    ------ ----------- ----------- --------- --------- ----------------
    100.00 0.799649 0 47083893 gettimeofday
    0.00 0.000000 0 6 1 clock_gettime
    ------ ----------- ----------- --------- --------- ----------------
    100.00 0.799649 47083899 1 total

    real 22m28.796s
    user 2m5.124s
    sys 12m45.256s

    As you can see I ctrl+c'ed the process after 22 minutes.

    New (on a weaker laptop):
    wicked@wnote:~$ time strace -c -e "gettimeofday,clock_gettime" node 3.js
    % time seconds usecs/call calls errors syscall
    ------ ----------- ----------- --------- --------- ----------------
    -nan 0.000000 0 3 clock_gettime
    ------ ----------- ----------- --------- --------- ----------------
    100.00 0.000000 3 total

    real 0m8.761s
    user 0m8.741s
    sys 0m0.016s

    The difference is obvious :)

    понедельник, 29 октября 2012 г., 19:38:37 UTC+7 пользователь Ben Noordhuis
    написал:
    On Mon, Oct 29, 2012 at 6:15 AM, Alexey Kupershtokh
    <alexey.ku...@gmail.com <javascript:>> wrote:
    I've found an extreme solution:

    I upgraded ubuntu from
    Ubuntu 12.04.1 LTS \n \l;
    Linux wnote 3.2.0-33-generic-pae #52-Ubuntu SMP Thu Oct 18 16:39:21 UTC 2012
    i686 i686 i386 GNU/Linux
    to
    Ubuntu 12.10 \n \l;
    Linux wnote 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012
    x86_64 x86_64 x86_64 GNU/Linux

    And performance increased 15-20 times to these numbers:

    Chrome 22: 10,946,261
    FF 16: 15,301,293
    Node 0.8.14: 11,671,335


    Differences are:
    ubuntu: 12.04 -> 12.10
    kernel: 3.2.0-33 -> 3.5.0-17
    arch: i686 + pae (32 bit) -> x86_64 (64 bit)

    I don't know which one matters, but it's a subject for further
    investigation.
    It's probably glibc/VDSO changes. I wager that when you trace your
    benchmark with `strace -c gettimeofday,clock_gettime`, you'll see a
    ton of hits on your old system and hardly any on your new system.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupnodejs @
categoriesnodejs
postedOct 25, '12 at 6:48p
activeOct 29, '12 at 3:44p
posts18
users5
websitenodejs.org
irc#node.js

People

Translate

site design / logo © 2022 Grokbase