By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,639 Members | 2,000 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,639 IT Pros & Developers. It's quick & easy.

Measuring recurring elapsed time

P: n/a
I'm a newbie at this, and have searched a lot but can't find something
that seems appropriate for measuring a recurring elapsed time.

Creating an object with: var mydate = new Date(); seems clear, as is
creating a second: nowTime = new Date(); and getting a difference
between the two.

My quesiton is what if you have many, maybe thousands of intervals you
wish to measure? Should I do: nowTime = new Date(); with every pass
of a loop, maybe thousands of times?
For example, if I wish download thousands of messages from a server and
report the average elapsed time, would I create a new Date() object
every time through a loop? Would you constantly assign the same var to
new Date() objects?

If so, is that some issue in javascript, maybe creating a memory leak or
needing some sort of garbage collection?
Or, when I say myTime = new Date() it takes the current date. Is there
no reset method to tell that object to reset again, like...

myTime.ResetThis() //does something like this exist?
Thanks...
Ross.
Nov 6 '08 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Ross wrote on 06 nov 2008 in comp.lang.javascript:
I'm a newbie at this, and have searched a lot but can't find something
that seems appropriate for measuring a recurring elapsed time.

Creating an object with: var mydate = new Date(); seems clear, as is
creating a second: nowTime = new Date(); and getting a difference
between the two.

My quesiton is what if you have many, maybe thousands of intervals you
wish to measure? Should I do: nowTime = new Date(); with every pass
of a loop, maybe thousands of times?
For example, if I wish download thousands of messages from a server and
report the average elapsed time, would I create a new Date() object
every time through a loop? Would you constantly assign the same var to
new Date() objects?
Just take the total time, and divide it by the number of messages.

>
If so, is that some issue in javascript, maybe creating a memory leak
or
needing some sort of garbage collection?
Or, when I say myTime = new Date()
Yu first have to define ["var"] the variable:

var myTime = new Date();
it takes the current date. Is there
no reset method to tell that object to reset again, like...

myTime.ResetThis() //does something like this exist?
No.

myTime is not a time, but a variable name pointing to a value that is of
the variant type "time".
There is no sense in "resetting" a pointer-to-a-value but to another
value.

Just setting it to something else changes the pointer:

myTime = undefined;

or

myTime = 'Hello world';

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Nov 6 '08 #2

P: n/a
On Nov 7, 6:01*am, Ross <ab...@fgh.ijkwrote:
I'm a newbie at this, and have searched a lot but can't find something
that seems appropriate for measuring a recurring elapsed time.
You will need to create your own stop watch or clock object to do
that.

Creating an object with: var mydate = new Date(); *seems clear, as is
creating a second: *nowTime = new Date(); and getting a difference
between the two.
So the next step is to create an object wtih start, stop, lap and
reset methods.
My quesiton is what if you have many, maybe thousands of intervals you
wish to measure? *Should I do: *nowTime = new Date(); *with everypass
of a loop, maybe thousands of times?
It depends. If you are just measuring simple elapsed time intervals,
that's all you need.

For example, if I wish download thousands of messages from a server and
report the average elapsed time, would I create a new Date() object
every time through a loop? Would you constantly assign the same var to
new Date() objects?
No, you'd need one variable to remember the start time, you may not
need to remember the second, e.g.:

var startTime = new Date();
// do stuff
var elapsedTime = new Date() - startTime; // Elapsed time in
milliseconds.
The elapsed time variable may not be necessary depending on what you
need the value for.

If so, is that some issue in javascript, maybe creating a memory leak or
needing some sort of garbage collection?
Not that I know of (but that's not saying much). The most infamous
leak regards IE, cicrular references involving DOM objects and
closures - avoidance and attenuation strategies are well known if that
becomes an issue.

Or, when I say myTime = new Date() it takes the current date. *Is there
no reset method to tell that object to reset again, like...

* * myTime.ResetThis() * * * * *//does something like this exist?
If you build your own myTime object, you can give it whatever methods
you think it needs. Otherwise, go to system preferences and change
the clock... :-)

The built-in Date object is defined in ECMA-262, implementations will
likely follow that pretty closely.

The following should get you started, it's written as a single object
but it could be turned into a constructor pretty easily so you could
have multiple stopwatches running at once:

var stopWatch = (function() {

var startTime;
var elapsedTime = 0;
var running = false;

return {
start: function () {
if (!running) {
startTime = new Date();
running = true;
}
},
stop: function() {
if (running) {
elapsedTime += new Date() - startTime;
startTime = null;
running = false;
}
return elapsedTime;
},
lap: function() {
if (running) {
return elapsedTime + (new Date() - startTime);
} else {
return elapsedTime;
}
},
reset: function () {
var t = this.lap();
startTime = null;
elapsedTime = 0;
running = false;
return t;
}
}
})();

--
Rob
Nov 6 '08 #3

P: n/a
Evertjan. wrote:
Ross wrote on 06 nov 2008 in comp.lang.javascript:
>I'm a newbie at this, and have searched a lot but can't find something
that seems appropriate for measuring a recurring elapsed time.

Creating an object with: var mydate = new Date(); seems clear, as is
creating a second: nowTime = new Date(); and getting a difference
between the two.

My quesiton is what if you have many, maybe thousands of intervals you
wish to measure? Should I do: nowTime = new Date(); with every pass
of a loop, maybe thousands of times?
For example, if I wish download thousands of messages from a server and
report the average elapsed time, would I create a new Date() object
every time through a loop? Would you constantly assign the same var to
new Date() objects?

Just take the total time, and divide it by the number of messages.
lol - Ok it was just an example - think instead building a histogram of
delays.
>
>If so, is that some issue in javascript, maybe creating a memory leak
or
>needing some sort of garbage collection?
Or, when I say myTime = new Date()

Yu first have to define ["var"] the variable:

var myTime = new Date();
>
> it takes the current date. Is there
no reset method to tell that object to reset again, like...

myTime.ResetThis() //does something like this exist?

No.

myTime is not a time, but a variable name pointing to a value that is of
the variant type "time".
There is no sense in "resetting" a pointer-to-a-value but to another
value.

Just setting it to something else changes the pointer:

myTime = undefined;

or

myTime = 'Hello world';
Thanks for the suggestions.
Nov 8 '08 #4

P: n/a
RobG wrote:
On Nov 7, 6:01 am, Ross <ab...@fgh.ijkwrote:
>I'm a newbie at this, and have searched a lot but can't find something
that seems appropriate for measuring a recurring elapsed time.

You will need to create your own stop watch or clock object to do
that.

>Creating an object with: var mydate = new Date(); seems clear, as is
creating a second: nowTime = new Date(); and getting a difference
between the two.

So the next step is to create an object wtih start, stop, lap and
reset methods.
>My quesiton is what if you have many, maybe thousands of intervals you
wish to measure? Should I do: nowTime = new Date(); with every pass
of a loop, maybe thousands of times?

It depends. If you are just measuring simple elapsed time intervals,
that's all you need.
I've implemented it now, and it seems to work well. I'm grabbing events
which need to be accurately sync'd to the mS, and nothings blown up yet,
so I assume it's working okay. I'll have to look around for a profiler
of some kind to get a sense of what resources I'm using.
>
>For example, if I wish download thousands of messages from a server and
report the average elapsed time, would I create a new Date() object
every time through a loop? Would you constantly assign the same var to
new Date() objects?

No, you'd need one variable to remember the start time, you may not
need to remember the second, e.g.:

var startTime = new Date();
// do stuff
var elapsedTime = new Date() - startTime; // Elapsed time in
milliseconds.
The elapsed time variable may not be necessary depending on what you
need the value for.
That looks about right. Thx that's reassuring.

>
>If so, is that some issue in javascript, maybe creating a memory leak or
needing some sort of garbage collection?

Not that I know of (but that's not saying much). The most infamous
leak regards IE, cicrular references involving DOM objects and
closures - avoidance and attenuation strategies are well known if that
becomes an issue.

>Or, when I say myTime = new Date() it takes the current date. Is there
no reset method to tell that object to reset again, like...

myTime.ResetThis() //does something like this exist?

If you build your own myTime object, you can give it whatever methods
you think it needs. Otherwise, go to system preferences and change
the clock... :-)

The built-in Date object is defined in ECMA-262, implementations will
likely follow that pretty closely.

The following should get you started, it's written as a single object
but it could be turned into a constructor pretty easily so you could
have multiple stopwatches running at once:

var stopWatch = (function() {

var startTime;
var elapsedTime = 0;
var running = false;

return {
start: function () {
if (!running) {
startTime = new Date();
running = true;
}
},
stop: function() {
if (running) {
elapsedTime += new Date() - startTime;
startTime = null;
running = false;
}
return elapsedTime;
},
lap: function() {
if (running) {
return elapsedTime + (new Date() - startTime);
} else {
return elapsedTime;
}
},
reset: function () {
var t = this.lap();
startTime = null;
elapsedTime = 0;
running = false;
return t;
}
}
})();

--
Rob
Thanks Rob, that all sounds good, and it's working well for me.

Ross.
Nov 8 '08 #5

P: n/a
Ross wrote on 08 nov 2008 in comp.lang.javascript:
>Just take the total time, and divide it by the number of messages.

lol - Ok it was just an example - think instead building a histogram of
delays.
Even if you do not have consecutive times, but just numbers coming in now
and then, you do not need to save them all to calculate the average.

var average = 0; // start value unimpotrant
var count = 0;

function calcul(nextNumber) {
average = (average * count + nextNumber) / ++count;
};

// testing:
calcul(2);
calcul(4);
calcul(2);
calcul(4);
calcul(2);
calcul(4);
alert(average); // 3.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Nov 8 '08 #6

P: n/a
"Evertjan." <ex**************@interxnl.netwrites:
var average = 0; // start value unimpotrant
var count = 0;

function calcul(nextNumber) {
average = (average * count + nextNumber) / ++count;
};
While a great idea in some cases, this way of doing it can cause problems
with rounding.
It might be better to keep the sum and the count, and then calculate
the everage (by dividing) when it's needed. That might still risk
overflowing the sum, but "average * count" above will do the same.

---
function Averager() {
this.sum = 0;
this.count = 0;
}
Averager.prototype.add = function add(n) {
this.sum += n;
this.count++;
};
Averager.prototype.average = function average() {
return this.sum / this.count;
}

var avg = new Averager();
avg.add(2);
avg.add(4);
avg.add(2);
avg.add(4);
avg.add(2);
avg.add(4);
alert(avg.average()); // 3.
---

(It's much harder to find, e.g., the spread efficiently :)

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Nov 9 '08 #7

P: n/a
Lasse Reichstein Nielsen wrote on 09 nov 2008 in comp.lang.javascript:
While a great idea in some cases, this way of doing it can cause problems
with rounding.
It might be better to keep the sum and the count, and then calculate
the everage (by dividing) when it's needed. That might still risk
overflowing the sum, but "average * count" above will do the same.
As there is no specific rounding in the formula:

Are you sure that the precision overflowing ["rounding|?] of a floating
point division is worse than the precision overflowing of the floating sum?

The sum can also have exponent overflowing.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Nov 9 '08 #8

P: n/a
In comp.lang.javascript message <Xn********************@194.109.133.242>
, Sun, 9 Nov 2008 18:41:57, Evertjan. <ex**************@interxnl.net>
posted:
>
The sum can also have exponent overflowing.
The age of the Universe is currently about 13e9 * 365 * 864e5
milliseconds, say 4.1e20 ms.

JavaScript Numbers can go up to about 1.7e308.

Exponent overflow in JavaScript time sums seems not immediately likely.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Nov 9 '08 #9

P: n/a
Dr J R Stockton wrote on 09 nov 2008 in comp.lang.javascript:
In comp.lang.javascript message <Xn********************@194.109.133.242>
, Sun, 9 Nov 2008 18:41:57, Evertjan. <ex**************@interxnl.net>
posted:
>>
The sum can also have exponent overflowing.

The age of the Universe is currently about 13e9 * 365 * 864e5
milliseconds, say 4.1e20 ms.

JavaScript Numbers can go up to about 1.7e308.

Exponent overflow in JavaScript time sums seems not immediately likely.
You are right in the case of time measurement as in the OQ, John,
but the technique of running avarage has other uses,
that perhaps could.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Nov 9 '08 #10

This discussion thread is closed

Replies have been disabled for this discussion.