Handle Leaks with Microsoft.XMLDOM
tyd...@gmail.com
machines. The leak APPEARS to be handles to the registry key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap
The below code runs on a timer running several times per second and
after about 15-30 minutes or so, it runs out of handles and crashes IE.
I found an article on msdn discussing how setting properties in this
way could cause memory leaks if the reference to the nodeValue in the
div isn't set to null before leaving the page (they suggest doing this
in an unload function though of course, that does not quite work here
since we aren't unloading... we're just constantly updating the data).
Instead, as you can see below, I've set the div's innerHTML to null
prior to resetting it.... to no avail. Any help would be much
appreciated.
--Mike
var currentId;
var responseXML;
var xmlDoc;
var xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
xmlhttp.open("POST", "<URL>" //where <URL> is the url that is
responding with xml data
xmlhttp.onreadystatechange=function()
{
if (xmlhttp.readyState==4)
{
responseXML = xmlhttp.responseText;
xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.loadXML(responseXML);
for (i=0; i<xmlDoc.documentElement.attributes.length;
i++)
{
currentId =
xmlDoc.documentElement.attributes[i].nodeName;
document.getElementById(currentId).innerHTML =
null;
document.getElementById(currentId).innerHTML =
xmlDoc.documentElement.attributes[i].nodeValue; //Note:
Commenting out this line removes the handle leak.... but of course that
also prevents my data from updating.
}
delete xmlDoc;
xmlDoc = null;
responseXML = null;
}
xmlhttp.send(null);
delete xmlhttp;
xmlhttp = null;
VK
tyd...@gmail.com wrote:
> I have a problem where the below code chunk causes handle leaks on some
> machines. The leak APPEARS to be handles to the registry key:
>
> HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
> Settings\ZoneMap
>
> The below code runs on a timer running several times per second and
> after about 15-30 minutes or so, it runs out of handles and crashes IE.
>
> I found an article on msdn discussing how setting properties in this
> way could cause memory leaks if the reference to the nodeValue in the
> div isn't set to null before leaving the page (they suggest doing this
> in an unload function though of course, that does not quite work here
> since we aren't unloading... we're just constantly updating the data).
>
> Instead, as you can see below, I've set the div's innerHTML to null
> prior to resetting it.... to no avail. Any help would be much
> appreciated.
1. If your form's content allows that, try to switch from POST method
to GET and use send("") or (next to try) send(/*nothing*/) instead of
send(null)
2. Try to make a global counter for pending requests and do not let it
go over some limit: increase on each new request, decrease on each
successful request.
I would bet on #2 as the real problem but don't kill if I'm wrong.
tydbowl
I tried all of these options and the leak still occurs.
Any other ideas anyone?
VK
> > I have a problem where the below code chunk causes handle leaks on some
> > machines. The leak APPEARS to be handles to the registry key:
OK: first of all let's us narrow the problem: where does the leak
occur: in IXMLHTTPRequest or in DOM methods.
Forget for a second about AJAX - you don't need it really in IE. There
is much more reliable and convenient download behavior (build-in since
5.0)
<html xmlns:IE>
<head>
<title>Test</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">
var counter = 0;
function onDownloadDone(content) {
counter++;
$('out').innerHTML = content;
document.forms[0].elements[0].value = counter;
// IE doesn't operate with the real time but with
// system ticks - 60ms per tick
// so setTimeout(...,0,10,25,59) all means 60
setTimeout('fun()');
}
function fun() {
var spice = '?' + (new Date()).getTime();
// You may guess that "data.xml" should be provided:
$('loader').
startDownload('data.xml'+spice, onDownloadDone);
}
function $(id) {
return document.getElementById(id) || null;
}
</script>
<style type="text/css">
body { background-color: #FFFFFF}
</style>
</head>
<body onload="fun()">
<IE:Download id="loader" style="behavior:url(#default#download)" />
<div id="out"> </div>
<form>
Loops: <input type="text" name="cnt">
</form>
</body>
</html>
On my test Win98 SE / IE 6.0 it held 3,000 loops like no problem. I
just cannot reserve the computer for the entire day to see the
"work-on-denial" limit but it's definitely not 30-40 loops like in your
case. You have to improve your algorithm I guess.
tydbowl
machine.
Just some additional info: My original code does NOT have handle leaks
on most machines, but it does on a few. The system info for the
problematic machine is:
Windows XP SP2
IE version: 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
Thanks again for that sample. Unfortunately, the code needs to support
firefox, mozilla, and opera, so I'm not sure if the xmlns:IE and the
IE:Download tags will be supported... but I'll give it a shot and let
you know.
Thanks,
--Mike
VK
Behaviors are IE-exclusive, so it will not work for Firefox or Opera.
I gave this code to narrow the possible leak source: <download>
behavior doesn't leak for sure for IE 5.5 and higher. I just checked it
on Windows XP SP1 for 5,000 loops.
So you may want to run this sample exactly as it is on the machines of
question to see their work-on-denial limit. If it still crashes any
soon then the problem is:
1) either in the JScript / MSXML behavior difference
2) or in some DOM holes (for example innerHTML was known to be leaky -
but long time ago).
JScript has special versioning methods:
alert(ScriptEngineMajorVersion() + '.' + ScriptEngineMinorVersion())
will give you the actual JScript version running on the machine.
Compare it.
If the machine of the question has a lower version, update JScript
from:
<http://msdn.microsoft.com/library/default.asp?url=/downloads/list/webdev.asp>
tydbowl
out the line of code next to the "Note:" in my original sample, the
leaks also dissappear.
It appears the leaks only occur when I set the innerHTML to the value
of an XMLDOM node.
Also I checked the JScript version as you suggested. Both leaky and
non leaky machines print out "5.6" (.... Though I'm admittedly not
sure if the JScript version is the samething as the javascript
version... I don't know enough about the two terms to know if they are
really different under the covers).
I'm going to play with that sample and replace the "$('out').innerHTML
= content;" line with the XMLDOM code from the original sample and see
if the leak occurs. I presume it will.
VK
tydbowl wrote:
> Though I'm admittedly not
> sure if the JScript version is the samething as the javascript
> version... I don't know enough about the two terms to know if they are
> really different under the covers).
Mozilla Foundation (and many others) is going by the conventional
versioning where JavaScript 1.0 is the first one in Netscape 2.x and
JavaScript 1.5 is the current one.
ECMA docs are based on the description of Netscape 4.? (don't remember
- 4.5 or something) They have something atop of 1.2 and something
missing from 1.3 (minus all Netscape stuff ECMA considered to be not
enough academical). So it's kind of 1.2+/- or 1.3-- :-)
Microsoft mainly goes by Internet Explorer versions: so JScript 5.5 was
first shipped with IE 5.5.
*Approximately* JavaScript 1.5 corresponds to JScript 5.5 (keeping in
mind all browser-specific features) and this was the basic ground for
several last years.
> I'm going to play with that sample and replace the "$('out').innerHTML
> = content;" line with the XMLDOM code from the original sample and see
> if the leak occurs. I presume it will.
May I see what are you actually inserting into innerHTML?
You may put any foobar text content but keep all tags
Thomas 'PointedEars' Lahn
> tydbowl wrote:
>> Though I'm admittedly not
>> sure if the JScript version is the samething as the javascript
>> version... I don't know enough about the two terms to know if they are
>> really different under the covers).
>
> Mozilla Foundation (and many others) is going by the conventional
> versioning where JavaScript 1.0 is the first one in Netscape 2.x and
> JavaScript 1.5 is the current one.
What "conventional versioning" are you talking about? JavaScript is an
independent language implementation, of course its versioning is different
than other (ECMAScript) implementations.
> ECMA docs are based on the description of Netscape 4.? (don't remember
> - 4.5 or something) They have something atop of 1.2 and something
> missing from 1.3 (minus all Netscape stuff ECMA considered to be not
> enough academical). So it's kind of 1.2+/- or 1.3-- :-)
Nonsense. As the ECMAScript Specification and the JavaScript Guide(s)
state,
- ECMAScript 1 was based on JavaScript 1.1 (NN3) and JScript 1.0 (IE3).
- JavaScript 1.2 (NN 4.0-4.05) is not fully compatible with ECMAScript 1.
- JavaScript 1.3 (NN 4.06-4.8) is fully compatible with ECMAScript 1.
- JavaScript 1.4 (not implemented to my knowledge) is fully compatible
with ECMAScript 1.
- JavaScript 1.5 (Mozilla/5.0 browsers incl. NN6) is fully compatible
with ECMAScript 3.
- JavaScript 1.6 (Mozilla/5.0 rv:1.8b+ browsers incl. upcoming Firefox 1.5)
is probably fully compatible with ECMAScript 3 (CMIIW).
Unfortunately, there is no such compact description for JScript versions in
the MSDN Library. However, Microsoft explicitly states several features in
JScript (.NET) not to be "ECMAScript compliant" or "not provided by the
ECMAScript language":
<URL:http://msdn.microsoft.com/library/en-us/script56/html/js56jsoriVersionInformation.asp>
<URL:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/jscript7/html/jsgrpnonecmafeatures.asp>
> Microsoft mainly goes by Internet Explorer versions: so JScript 5.5 was
> first shipped with IE 5.5.
True, however unlike JavaScript versions, JScript versions are independent
of the browser version in a way that the Script Engine can be upgraded
independently. Hence JScript 5.5 is the minimum version that can be
expected on IE 5.5 _for Windows_ (there appears to be a difference in
script support between in IE versions for Windows and IE versions for Mac).
> *Approximately* JavaScript 1.5 corresponds to JScript 5.5 (keeping in
> mind all browser-specific features) and this was the basic ground for
> several last years.
That remains to be seen. I do not think you have the knowledge required to
assess that. Neither have I yet, however I think my feature support matrix
on <URL:http://www.pointedears.de/scripts/js-version-info> will allow me to
assess that once it is complete.
PointedEars
Richard Cornford
<snip>
> ECMA docs are based on the description of Netscape 4.?
> (don't remember - 4.5 or something) They have something
> atop of 1.2 and something missing from 1.3 (minus all
> Netscape stuff ECMA considered to be not enough academical).
> So it's kind of 1.2+/- or 1.3-- :-)
I realise that you consider the stories in your head as more true than
anything else, but do you really think that it does anyone any good at
all for you to be posting this pack of lies?
Richard.
Dr John Stockton
, dated Mon, 28 Nov 2005 09:38:59, seen in news:comp.lang.javascript, VK
<school...@yahoo.com> posted :
>
> // IE doesn't operate with the real time but with
> // system ticks - 60ms per tick
> // so setTimeout(...,0,10,25,59) all means 60
>
Misleadingly inaccurate.
In Win98, IE4 uses ticks at about 54.9 ms intervals, and new Date() has
a resolution of 10 ms.
The interval and resolution depend on the OS/browser combination, I've
been told that IE on Mac OS X gives 1 ms for both.
AISB, read the newsgroup FAQ; see below.
More results for/from
<URL:http://www.merlyn.demon.co.uk/js-dates.htm#Ress>
would be appreciated.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Randy Webb
<snip>
> More results for/from
> <URL:http://www.merlyn.demon.co.uk/js-dates.htm#Ress>
> would be appreciated.
IE6 on Win XP SP2 gives me 15.6/15.7 for Update Interval. It alternates
between the two for the most part. Numerical Resolution of 1.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Kevin Darling
> I have a problem where the below code chunk causes handle leaks on some
> machines. The leak APPEARS to be handles to the registry key:
>
> HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
> Settings\ZoneMap
Have you tried making -- xmlDoc = new
ActiveXObject("Microsoft.XMLDOM"); -- a static variable instead of
creating it each time?
Is there any security involved as far as accessing the server?
> The below code runs on a timer running several times per second and
> after about 15-30 minutes or so, it runs out of handles and crashes IE.
Is it possible that the webserver is running out of connections?
That'll mess up xmlhttp sometimes.
Also, be aware that in some IE 6's, if you use onUnload you sometimes
have to also call abort() on xmlhttp to clear things up correctly. (I
know this isn't your case, though.)
Another suggestion is to not only make the xmlDoc a static, but avoid
using your "responseXML" as an intermediary variable. Perhaps directly
use:
xmlDoc.loadXML(xmlhttp.responseText)
And instead of creating a function each time for the
xmlhttp.onreadystatechange, just point to a static one.
Just some ideas,
Kev
rf
> JRS: In article <1133199539.4...@g44g2000cwa.googlegroups.com>
> , dated Mon, 28 Nov 2005 09:38:59, seen in news:comp.lang.javascript, VK
> <school...@yahoo.com> posted :
>>
>> // IE doesn't operate with the real time but with
>> // system ticks - 60ms per tick
>> // so setTimeout(...,0,10,25,59) all means 60
>>
>
> Misleadingly inaccurate.
>
> In Win98, IE4 uses ticks at about 54.9 ms intervals, and new Date() has
> a resolution of 10 ms.
>
> The interval and resolution depend on the OS/browser combination,
Not inaccurate, merely misleading.
The timer tick interval depends on the OS and has nothing to do with the
browser.
The win9x family of operating systems use an interval of 54 odd ms. The NT
family differ. I cannot recall what NT3.x and NT4 use but NT5 (2000) and
NT5.1 (XP) use 15 odd ms although some have been reported to use 10 odd ms.
Windows server 2003 uses 100ms or 200ms, can't remember which.
The resolution of any function that access the system clock (which is
updated at timer tick) would be exactly the same as the timer tick. There
is, after all, only one clock.
There are low level API functions which will change the timer tick interval
as a side effect but these functions would rarely be used by a normal
application like a browser as they are not aimed at time but rather
performance in near real time multithreaded applications.
> I've
> been told that IE on Mac OS X gives 1 ms for both.
The documentation that details the above low level functions (microsoft of
course) warns that causing the timer tick to drop below 2ms can have
disasterous results on system performance. Perhaps Mac OS X uses a
different architecture to maintain the system clock.
--
Cheers, Richard.
Richard Cornford
<snip>
> The resolution of any function that access the system clock
> (which is updated at timer tick) would be exactly the same
> as the timer tick. There is, after all, only one clock.
I am not sure that you can go that far. The resolution of a function
that accesses the system clock can be no better than the OS tick, but it
could be worse.
Richard.
VK
Dr John Stockton wrote:
>> VK <school...@yahoo.com> posted :
> > // IE doesn't operate with the real time but with
> > // system ticks - 60ms per tick
> > // so setTimeout(...,0,10,25,59) all means 60
>
> Misleadingly inaccurate.
>
> In Win98, IE4 uses ticks at about 54.9 ms intervals, and new Date() has
> a resolution of 10 ms.
As I like to say: "Do not mix a God's gift with a omlet" (means "to do
not think the same on two totally diffrent things").
When you run a separate application it can be only as accurate as the
system tick of the particular OS (50ms? on Win98 -... - 10ms? on
Linux).
If you want a better accuracy (say bor benchmarking) you have to
program a low-level hardware access to the system clock.
When you run a JavaScript program it can be only as accurate as the
system tick set for the host application which is Internet Explorer in
our case.
Nevertheless the system usually keeps you out of this timing "misery",
so say in Java you even can use nanoseconds and still get some
true-looking results. It achieved by calculating the average interval
by formula ms = (system tick)*(n of ticks) + (lower byte spice)
This explain some fantastic system ticks like 54.9 ms ;-) I assure you
that no system runs on such periods.
More useful reading (besides OS specs) :
<http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/truespeed.asp>
Martin Nedbal
microsoft.public.windows.inetexplorer.ie6.browser and it should go here
as well.
> I have a problem where the below code chunk causes handle leaks on some
> machines. The leak APPEARS to be handles to the registry key:
>
> HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
> Settings\ZoneMap
>
Hi,
I'm just fighting exactly the same problem, but I don't think that this
is only related to XMLHTTP. I have latest WindowsXP (SP2+windowsupdate,
IE version 6.0.2900.2180.xpsp_sp2_gdr.050301-1519). My IE seems to open
new handles each time I :
. set src on SCRIPT element (2 handles)
. set src on IFRAME element (2 handles)
. set src on IMG elment (2 handles)
. set innerHTML propery to some text (=no new elements) on DIV (or any
other visual element) (2 handles)
IE starts with 12 handles (having about:blank as homepage), then it
takes randomly another 2 or 4 handles each time I load the age/press
F5. This appears even if the page loaded is a 403 for instance. It's
not related to user auth scheme (I found this problem in out
application which is using NTML but it's the same even for anonymous
access). It's not related to membership of the server in zones - it
does the same when I put the server into "trusted" and when it's not
there. I've created small test page which allows you to test the
actions I mentioned (http://linda.cooper.cz/awe/test/ie/).
When the number of opened handles reaches 64k IE partly stops working,
if you had a server in "trusted" zone it starts to recognize it as
"internet" etc.
I'm going to test that on clean WindowsXP and then after each
servicepack/IE update to find the one which caused this problem but
this will take some time. Another clue might be that this behavior
can't be reproduced on Windows 2000 (SP4+windowsupdate).
Feel free to contact me if you need to clarify things/get additional
information.
With regards,
Martin
Dr John Stockton
Tue, 29 Nov 2005 18:40:50 local, seen in news:comp.lang.javascript,
Randy Webb <HikksNo...@aol.com> posted :
>Dr John Stockton said the following on 11/29/2005 3:07 PM:
>
><snip>
>
>> More results for/from
>> <URL:http://www.merlyn.demon.co.uk/js-dates.htm#Ress>
>> would be appreciated.
>
>IE6 on Win XP SP2 gives me 15.6/15.7 for Update Interval. It alternates
>between the two for the most part. Numerical Resolution of 1.
Thank you; entered. If you increase Loop Count to 100 you should get
15.62/15.63; to 1000, 15.625, if not interrupted.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Martin Nedbal
hotfix 896688, the only trouble is that it fixes quite a holes in
security :(
Dr John Stockton
Nov 2005 01:27:40 local, seen in news:comp.lang.javascript, Richard
Cornford <Ric...@litotes.demon.co.uk> posted :
A browser writer *could* go further.
In the PC architecture, the 54.9 ms clock is obtained by division by
65536, and the signal that drives that can be divided by other numbers.
Signals of much higher frequency can be read in Win98/PII and higher -
there's the RDTSC instruction, and the performance counter.
Additionally, there's the PC RTC, driven by a 32 kHz crystal, which
could be used.
--
Dr John Stockton
, dated Tue, 29 Nov 2005 23:16:32 local, seen in
>>> VK <school...@yahoo.com> posted :
>> > // IE doesn't operate with the real time but with
>> > // system ticks - 60ms per tick
>> > // so setTimeout(...,0,10,25,59) all means 60
>>
>> Misleadingly inaccurate.
>>
>> In Win98, IE4 uses ticks at about 54.9 ms intervals, and new Date() has
>> a resolution of 10 ms.
>
>As I like to say: "Do not mix a God's gift with a omlet" (means "to do
>not think the same on two totally diffrent things").
If you were to write only on what you understand, this newsgroup would
be much emptier.
>When you run a separate application it can be only as accurate as the
>system tick of the particular OS (50ms? on Win98 -... - 10ms? on
>Linux).
Don't confuse accuracy, resolution, and change interval.
>Nevertheless the system usually keeps you out of this timing "misery",
>so say in Java you even can use nanoseconds and still get some
>true-looking results. It achieved by calculating the average interval
>by formula ms = (system tick)*(n of ticks) + (lower byte spice)
>
>This explain some fantastic system ticks like 54.9 ms ;-) I assure you
>that no system runs on such periods.
Every PC has an interrupt at nominally 54.925495.. ms, which corresponds
to 18.206481...Hz. That's about 2^16 ticks per hour, and exactly
0x1800B0 ticks per 24 DOS hours.
The 18.2 Hz is in fact 1.19 MHz divided by 65536 in Timer Channel 0; the
1.19 MHz is a twelfth of 14.3 MHz, which is traditionally on ISA bus pin
30B, and that is 315.0/22 MHz, and 315/22/4 MHz is the US NTSC TV "color
sub-carrier" frequency, which was used by CGA, and 315/22/3 MHz is 4.77
MHz, the original PC clock frequency.
See <URL:http://www.merlyn.demon.co.uk/pas-time.htm> and Kris
Heidenstrom's The Timing FAQ</a> :
358631 Feb 1 1996 ftp://garbo.uwasa.fi/pc/programming/pctim003.zip
pctim003.zip Timing on the PC under MS-DOS, K.Heidenstrom
Every DOS PC has a 54.9 ms interrupt, and *at least* up to Win98 every
Windows DOS box can see it.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
rf
> JRS: In article <dmiv6e$knn$1$8300...@news.demon.co.uk>, dated Wed, 30
> Nov 2005 01:27:40 local, seen in news:comp.lang.javascript, Richard
> Cornford <Ric...@litotes.demon.co.uk> posted :
>>rf wrote:
>><snip>
>>> The resolution of any function that access the system clock
>>> (which is updated at timer tick) would be exactly the same
>>> as the timer tick. There is, after all, only one clock.
>><snip>
>>
>>I am not sure that you can go that far. The resolution of a function
>>that accesses the system clock can be no better than the OS tick, but it
>>could be worse.
>
> A browser writer *could* go further.
But I severely doubt any of them do.
> In the PC architecture, the 54.9 ms clock is obtained by division by
> 65536, and the signal that drives that can be divided by other numbers.
> Signals of much higher frequency can be read in Win98/PII and higher -
No. The PC architecture _provides_ a low frequeny counter. It is up to the
operating system to program that counter to its desired settings.
In any case the system clock is only a side effect of the timer tick
interrupt. There are far more important things also hanging off the timer
tick, such as scheduling time slices for each running thread.
Fiddle with the timer tick *at your own peril*. It is, though, very hard to
do this anyway. The hardware access is buried in the kernel.
> there's the RDTSC instruction,
> and the performance counter.
You mean the high-resolution performance counter? Which reports the
contents of the hardware time-stamp counter, which is accessed with the
RDTSC instruction?
This is there to investigate performance, not to schedule time dependent
events.
In any case if one _were_ able to cause the performance counter to schedule
anything then the thread that handled that anything would only be itself
sheduled *during its next time slice*. That is, at the next timer tick, or
later.
Windows is *not* a real time operating system. The granularity of the
entire system is the timer tick interval. Add a few other running threads
and the odd non-timer interrupt and, as Richard Cornford pointed out, it
becomes worse.
> Additionally, there's the PC RTC, driven by a 32 kHz crystal, which
> could be used.
How?
Regardless, this is drifting a little bit away from Javascript, except to
say that you will never get a time resolution better than the timer tick
using any of the javascript date/time functions. Indeed it will usually be
less. For once VK is right. Well, almost right :-)
--
Cheers, Richard.
VK
Dr John Stockton wrote:
> If you were to write only on what you understand, this newsgroup would
> be much emptier.
Would you mind?
<html>
<head>
<title>Timer</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
var c = 1000;
var d = 0;
var t1 = null;
var t2 = null;
function fStart(t) {
t1 = (new Date()).getTime();
if (typeof t == 'undefined') {
setTimeout('tick1()');
}
else {
d = t;
alert(d);
setTimeout('tick2()',d);
}
}
function tick1() {
c--;
document.forms[0].elements['out'].value = c;
if (c > 0) {
setTimeout('tick1()');
}
else {
t2 = (new Date()).getTime();
prompt('Milliseconds elapsed:',t2-t1);
}
}
function tick2() {
c--;
if (c > 0) {
setTimeout('tick1()',d);
}
else {
t2 = (new Date()).getTime();
prompt('Milliseconds elapsed:',t2-t1);
}
}
</script>
</head>
<body>
<form method="post" action="">
setTimeout(myFunction,<br>
<input type="button" name="b01" value="-" onclick="fStart()">
<input type="button" name="b02" value="10" onclick="fStart(10)">
<input type="button" name="b03" value="50" onclick="fStart(50)">
<input type="button" name="b04" value="60" onclick="fStart(60)">
) <br>
<input type="text" name="out" size="6" value="1000">
</form>
</body>
</html>
Also if you lucky enough you see the counter freezes from time to time
when the system rearranges the swap file. You know when you are not
doing anything long enough, your drive starts like "zip, zip, zip"? And
simetimes like "zip, ziiiip, zip"? This is the system got the message
"process idle" and decided to clean up the swap file to not waste the
time. And it's right because the process (Internet Explorer) *is* idle,
and your JavaScript inside the Internet Explorer *is not* a system
process. It's some crap inside the browser the system doesn't care
about - it is totally up to the browser how to handle it.
This issue has been also experienced by whoever decided to write some
a** kicking and breath taking Java applet. Namely if you run really
long and resource consuming thread (say FTP up/download) the applet
productivity falls down with time, and no thread priority helps.
VK
if system decides that your new Date() request fits into the current
time frame, it will give it to you. If not then you'll have to wait
another 60ms till the next time frame.
So the Date object can be only accurate up to (1+60)/2 = +/- 30ms
average error with 60ms max error.
It doesn't mean of course that you cannot make any benchmarking: you
just need to make enough of loops to overcome all possible
fluctuations.
rf
> Dr John Stockton wrote:
>> If you were to write only on what you understand, this newsgroup would
>> be much emptier.
>
> Would you mind?
Would I mind what?
Oh, correct your incorrect code. Well, yes I suppose I can.
Phase 1: Determine what code is supposed to do.
Hmmm. From the looks of the buttons and the countdown box I assume you are
attempting to determine how long one thousand launches of a setTimeout
function will take. <checks code> Yep. Seems so.
Phase 2: Run presented code
OK. Every button, after announcing its timeout value, proceeds to count
down the box and then reports a number of elapsed seconds. Hmmm. They are
always just above 15.odd seconds. How odd. With a timeout period of 60ms I
would expect elapsed to be above, say, 60+ seconds. Something is wrong
here.
Phase 3: Eyeball code.
<snip some code>
> function tick2() {
> c--;
> if (c > 0) {
> setTimeout('tick1()',d);
Here we are. For any timeout period except for the "undefined" one we come
to here and then what do we do? We set a timeout specifying not our timeout
function but the one that does not specify a timeout period.
You blithering idiot, the above line should read
setTimeout('tick2()',d);
Yes, tick2, not tick1.
Did you even test this rubbish?
Phase 3: Test code.
When I correct this obvious mistake I recieved the results I expected.
The 10 button: 17+ seconds. Just about right, given that the timeslice on
my system is 15 odd ms. Looks like, with all the things I have running, IE
misses the next timeslice two out of 15 times, because somebody else has
pre-empted it.
The 50 and 60 button: 63+ to 64+ seconds. Yep. as expected.
When I change your 10 button to 20 what should I get? Well I predict about
30+ ms. <checks/> 32.5 ms.
What about 30? <checks> 32.5 ms
What about 33? Ah. 48+ seconds. Three times my system clock granularity :-)
<snip rest of code>
Phase 4. Results.
I don't know what *your* code was meant to demonstrate but this exercise
has proceeded as I expected and has proved what I have stated elsewhere:
the granularity of the Windows operating system is fixed at some specific
value. 15+ms for NT+ and 54+ms for 9x. I don't know what *your* code was
meant to demonstrate.
> Also if you lucky enough you see the counter freezes from time to time
Yep. Perhaps JScript is doing some garbage collection. Perhaps your email
client woke up and checked for incoming.
> when the system rearranges the swap file.
Swap file? Windows 3.x had a "swap" file, or was it windows 2?
Current versions of windows do not have a swap file. The closest thing that
I can think of is the page file. The page file does *not* need to be
rearranged.
> You know when you are not
> doing anything long enough, your drive starts like "zip, zip, zip"? And
> simetimes like "zip, ziiiip, zip"?
Sounds very much like the (default ON) "index this hard disk for quick
search". Windows spends its spare time rebuilding the index for each folder
in the file system. You do know that windows does this, don't you?
> This is the system got the message
> "process idle"
There is no such message.
> and decided to clean up the swap file to not waste the
> time.
See above.
> And it's right because the process (Internet Explorer) *is* idle,
What about all of the other processes that are currently running. Just
because IE is idle causes windows to do something? I really don't think so.
> and your JavaScript inside the Internet Explorer *is not* a system
> process. It's some crap inside the browser the system doesn't care
> about - it is totally up to the browser how to handle it.
Left field. Straight through to the keeper. Over my head. Don't know what
the bloody hell you are talking about.
> This issue has been also experienced by whoever decided to write some
> a** kicking and breath taking Java applet. Namely if you run really
> long and resource consuming thread (say FTP up/download) the applet
> productivity falls down with time, and no thread priority helps.
You really should learn a little about how computers and all the software
that goes with them really work. You may then have some chance of becoming
a real programmer.
BTW you initialize the variable c on page load but fail to re-initialize it
on button click. This means your "code" only works once per page load.
Click another button and spurious results present. To make it work again
one must refresh the page.
This is a standard newbie programmer mistake and places your skill level
exactly.
--
Cheers, Richard.
rf
> and naturally Date object itself cannot be more exact then one tick:
Correct.
> if system decides that your new Date() request fits into the current
> time frame, it will give it to you. If not then you'll have to wait
> another 60ms till the next time frame.
Rubbish. A Date() request merely accesses the current value of the system
clock. There is no waiting. The "system" does nothing other than report the
current date/time.
> So the Date object can be only accurate up to (1+60)/2 = +/- 30ms
> average error with 60ms max error.
And under an NT+ operating system? Windows 2003?. Linux? A MAC? A Sun
workstation? *My* operating system?
Yes, in *my* OS I vary the timer tick at will. I have a near real time
application (that I market quite successfully) that sets the interval to
2ms. If my application is running then you get 2ms resolution. If it's not
running then you get the standard XP 15sm or the standard 9x 54ms.
Window CE by the way (the OS that might be inside your telephone) uses a
1ms interval.
I can envisage a real time system where the date/time functions *are* real
time, to the nanosecond.
So, in the wild one really does not know the resolution of the date/time
functions and one should not care.
You really don't know what you are talking about. Stop now.
> It doesn't mean of course that you cannot make any benchmarking: you
> just need to make enough of loops to overcome all possible
...
> fluctuations.
Well, fluct you americans as well :-)
--
Cheers, Richard.
VK
rf wrote:
> You blithering idiot, the above line should read
OK, Mr. Hope Of The World Programming, I admit I collected this code by
copy'n'paste from my files and I posted wrong sample. Tomas "Pointed
Ears" at such occasions doesn't harass anyone for several hours just to
celebrate. (Should I post more of evident errors?)
Here is the code I had. But before to proceed let's us recall what are
we talking about: I say that setTimeout / setInterval is not going by
real milliseconds but by system ticks set by the browser. Thusly any
time arguments are internally equal until you cross the border from one
system tick to another one. Thusly say setTimeout(f), setTimeout(f,0),
setTimeout(f,10) or setTimeout(f,25) are internally equal - lesser some
fluctuations caused by the system from one run to another.
<html>
<head>
<title>Timer</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
var c = 1000;
var d = 0;
var t1 = null;
var t2 = null;
function fStart(t) {
c = 1000;
t1 = (new Date()).getTime();
if (typeof t == 'undefined') {
setTimeout('tick1()');
}
else {
d = t;
setTimeout('tick2()',d);
}
}
function tick1() {
c--;
document.forms[0].elements['out'].value = c;
if (c > 0) {
setTimeout('tick1()');
}
else {
t2 = (new Date()).getTime();
prompt('Milliseconds elapsed:',t2-t1);
}
}
function tick2() {
c--;
document.forms[0].elements['out'].value = c;
if (c > 0) {
setTimeout('tick2()',d);
}
else {
t2 = (new Date()).getTime();
prompt('Milliseconds elapsed:',t2-t1);
}
}
</script>
</head>
<body>
<form method="post" action="">
setTimeout(myFunction,<br>
<input type="button" name="b01" value="-" onclick="fStart()">
<input type="button" name="b02" value="10" onclick="fStart(10)">
<input type="button" name="b03" value="50" onclick="fStart(50)">
<input type="button" name="b04" value="54" onclick="fStart(54)">
<input type="button" name="b04" value="55" onclick="fStart(55)">
<input type="button" name="b04" value="56" onclick="fStart(56)">
<input type="button" name="b04" value="60" onclick="fStart(60)">
) <br>
<input type="text" name="out" size="6" value="1000">
</form>
</body>
</html>
P.S.
> Swap file? Windows 3.x had a "swap" file, or was it windows 2?
> Current versions of windows do not have a swap file.
... From what attempt did you say you finally got your "C" for CS? Just
from the 3rd one?! Wow, your prof was really good to you!
VK
VK wrote:
> Here is the code I had. But before to proceed let's us recall what are
> we talking about: I say that setTimeout / setInterval is not going by
> real milliseconds but by system ticks set by the browser. Thusly any
> time arguments are internally equal until you cross the border from one
> system tick to another one. Thusly say setTimeout(f), setTimeout(f,0),
> setTimeout(f,10) or setTimeout(f,25) are internally equal - lesser some
> fluctuations caused by the system from one run to another.
Oh yeh, the last note: despite the script reset now the [c] counter,
you still should close/open the window after each run for clearer
results. As some DOM manipulations are involved, IE will make some
rather extensive DOM buffering. By going left-to-right by buttons it
may imitate the time increase in some circumstances (but not always).
rf
> rf wrote:
>> You blithering idiot, the above line should read
> <snip>
>
> OK, Mr. Hope Of The World Programming, I admit I collected this code by
> copy'n'paste from my files and I posted wrong sample.
Do you not think that in a technical newsgroup such as this you should post
code that actually works, that actually supports your statement, not
something that is wrong, something the actually negates your statement"?
Do you do this in real life? Release the "wrong" code to your customer?
I, "Mr. Hope Of The World Programming" or not, for one at least test my
code before publishing it.
--
Cheers, Richard.
Thomas 'PointedEars' Lahn
> rf wrote:
>> You blithering idiot, the above line should read
> <snip>
>
> OK, Mr. Hope Of The World Programming, I admit I collected this code by
> copy'n'paste from my files and I posted wrong sample. Tomas "Pointed
> Ears"
My first name is spelled Thomas, my nick name is spelled PointedEars.
> at such occasions doesn't harass anyone for several hours just to
> celebrate.
That is true. I never harass anyone for anything. It only is your weird
perception of my necessary corrections that make it seem so to you. Which
is interesting since you told quite a while ago you are going ignore me
because of that.
If you would get informed _once_ before you posted, and if you stopped
posting _provably wrong_ statements (in your holier-than-thou manner),
there would be no need for (such extensive) correction.
> (Should I post more of evident errors?)
No, the current ones are sufficient, thank you.
> Here is the code I had. But before to proceed let's us recall what are
> we talking about: I say that setTimeout / setInterval is not going by
> real milliseconds but by system ticks set by the browser. Thusly any
> time arguments are internally equal until you cross the border from one
> system tick to another one. Thusly say setTimeout(f), setTimeout(f,0),
> setTimeout(f,10) or setTimeout(f,25) are internally equal - lesser some
> fluctuations caused by the system from one run to another.
>
> <html>
> [...]
The DOCTYPE declaration is missing for Valid HTML. I do not want to
comment on your script code now, maybe later.
> P.S.
>> Swap file? Windows 3.x had a "swap" file, or was it windows 2?
>> Current versions of windows do not have a swap file.
>
> ... From what attempt did you say you finally got your "C" for CS? Just
> from the 3rd one?! Wow, your prof was really good to you!
Such ad hominem attacks will not help anyone. That goes for both of you.
PointedEars
Dr John Stockton
, dated Thu, 1 Dec 2005 04:19:02 local, seen in
news:comp.lang.javascript, VK <school...@yahoo.com> posted :
>Here is the code I had. But before to proceed let's us recall what are
>we talking about: I say that setTimeout / setInterval is not going by
>real milliseconds but by system ticks set by the browser. Thusly any
>time arguments are internally equal until you cross the border from one
>system tick to another one. Thusly say setTimeout(f), setTimeout(f,0),
>setTimeout(f,10) or setTimeout(f,25) are internally equal - lesser some
>fluctuations caused by the system from one run to another.
One of your problems is that you don't understand enough to see what is
wrong with what you write even when you are told what is wrong.
I used to think that you are an Indian; but I've changed my mind.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Dr John Stockton
1 Dec 2005 01:49:32 local, seen in news:comp.lang.javascript, rf
<r...@invalid.com> posted :
>Dr John Stockton wrote:
>
>> JRS: In article <dmiv6e$knn$1$8300...@news.demon.co.uk>, dated Wed, 30
>> Nov 2005 01:27:40 local, seen in news:comp.lang.javascript, Richard
>> Cornford <Ric...@litotes.demon.co.uk> posted :
>>>rf wrote:
>>><snip>
>>>> The resolution of any function that access the system clock
>>>> (which is updated at timer tick) would be exactly the same
>>>> as the timer tick. There is, after all, only one clock.
>>><snip>
>>>
>>>I am not sure that you can go that far. The resolution of a function
>>>that accesses the system clock can be no better than the OS tick, but it
>>>could be worse.
>>
>> A browser writer *could* go further.
>
>But I severely doubt any of them do.
Agreed.
>> In the PC architecture, the 54.9 ms clock is obtained by division by
>> 65536, and the signal that drives that can be divided by other numbers.
>> Signals of much higher frequency can be read in Win98/PII and higher -
>
>No. The PC architecture _provides_ a low frequeny counter. It is up to the
>operating system to program that counter to its desired settings.
Evidently you do not know all that much about the PC architecture, and
have not read the references that I provided.
It's not wise to reprogram the 18.2 Hz by altering the divider ratio;
but the 18.2*65536 Hz drives a three-channel counter, and at least one
channel can be used for other purposes, OS or end-user.
>In any case the system clock is only a side effect of the timer tick
>interrupt. There are far more important things also hanging off the timer
>tick, such as scheduling time slices for each running thread.
>
>Fiddle with the timer tick *at your own peril*. It is, though, very hard to
>do this anyway. The hardware access is buried in the kernel.
We were referring to whether the browser writer *could* access a higher
frequency (not raise *that* one; they are supposed to be skilled
professionals ...
Access seems easy enough in earlier versions of Windows.
>> there's the RDTSC instruction,
>> and the performance counter.
>
>You mean the high-resolution performance counter?
That is what I mean by performance counter - the one accessed by
QueryPerformanceCounter, not RDTSC (therefore the above "and").
> Which reports the
>contents of the hardware time-stamp counter, which is accessed with the
>RDTSC instruction?
But that (implemented AFAICS in the CPU) is not what I mean by
performance counter.
>This is there to investigate performance, not to schedule time dependent
>events.
But either *could* be read to provide better time resolution. I have
written a program, INT_TEST.PAS, with a resolution of (0.5 or 1.0)/1.19
us.
On my system, the performance counter is at 1.19 MHz and is 64-bit;
there is a Win32 API to access it ---
The QueryPerformanceCounter function retrieves the current value of
the high-resolution performance counter, if one exists.
BOOL QueryPerformanceCounter(
LARGE_INTEGER *lpliPerformanceCount
// address of current counter value
);
I've used it, in Delphi, without resort to ASM. Look it up in
Win32.hlp, if you can (my copy evidently came with Delphi). See in
TZ-CHECK, via <URL:http://www.merlyn.demon.co.uk/programs/00index.htm>
>In any case if one _were_ able to cause the performance counter to schedule
>anything then the thread that handled that anything would only be itself
>sheduled *during its next time slice*. That is, at the next timer tick, or
>later.
But not relevant. Reading time is not equivalent to scheduling.
>Windows is *not* a real time operating system. The granularity of the
>entire system is the timer tick interval. Add a few other running threads
>and the odd non-timer interrupt and, as Richard Cornford pointed out, it
>becomes worse.
>
>> Additionally, there's the PC RTC, driven by a 32 kHz crystal, which
>> could be used.
>
>How?
Write a driver, or whatever the current OS needs, to handle its
interrupt and to update a counter. Let the application read the
counter. I've processed the interrupt myself, in DOS; what I can do in
DOS a systems programmer can do in newer systems.
>Regardless, this is drifting a little bit away from Javascript, except to
>say that you will never get a time resolution better than the timer tick
>using any of the javascript date/time functions. Indeed it will usually be
>less. For once VK is right. Well, almost right :-)
That depends what you mean by the timer tick. If you mean the DOS timer
@ 18.2 Hz, then clearly Javascript in WinXP/IE6 beats that, using 64 Hz.
If you mean the timer tick that javascript uses, the remark is
tautologous.
rf
> JRS: In article <amiy1fx2g1r7.s...@40tude.net>, dated Thu,
> 1 Dec 2005 01:49:32 local, seen in news:comp.lang.javascript, rf
> <r...@invalid.com> posted :
>>Dr John Stockton wrote:
[timer resolution]
>>> A browser writer *could* go further.
>>
>>But I severely doubt any of them do.
>
> Agreed.
Fine, that is all we need to be aware of.
> Evidently you do not know all that much about the PC architecture, and
> have not read the references that I provided.
To the contrary, I know a great deal about PC architecture, to way back
before when there *were* PCs, just chips laying round on a breadboard, and
yes, I have read a couple of the references and find them sadly lacking,
for instance talking about the "DOS" clock for &deity;'s sake :-)
This *is* 2005 :-) You do *not* get to access the hardware any more and I
doubt that anybody of sane mind would include some sort of device driver
(and yes, I have written a few of them in my time so I know what they can
do) with a browser simply to get better timer resolution for some flashing
eye candy.
I really thought we were discussing the real world, with real operating
systems and real browsers. Evidently not.
I really don't need to pursue what some hyporthetical browser writer may in
theory do or not do. I have enough problems solving my bugs in the *real*
world :-)
--
Cheers, Richard.
Martin Nedbal
Repying again to my own post - I talked to Microsoft guys here in Czech
Republic and according to them this bug is confirmed and hotfix is
planned to arrive in Feb 2006.
Jasen Betts
> On 2005-12-02, rf <r...@invalid.com> wrote:
>> Dr John Stockton wrote:
>>
>>> JRS: In article <amiy1fx2g1r7.s...@40tude.net>, dated Thu,
>>> 1 Dec 2005 01:49:32 local, seen in news:comp.lang.javascript, rf
>>> <r...@invalid.com> posted :
>>>>Dr John Stockton wrote:
>>
>> [timer resolution]
>>
>>>>> A browser writer *could* go further.
>>>>
>>>>But I severely doubt any of them do.
>>>
>>> Agreed.
>>
>> Fine, that is all we need to be aware of.
>>
>>> Evidently you do not know all that much about the PC architecture, and
>>> have not read the references that I provided.
>>
>> To the contrary, I know a great deal about PC architecture, to way back
>> before when there *were* PCs, just chips laying round on a breadboard, and
>> yes, I have read a couple of the references and find them sadly lacking,
>> for instance talking about the "DOS" clock for &deity;'s sake :-)
>
> with a few lines of C. these give precision better than 1 microsecond.
>
>> This *is* 2005 :-) You do *not* get to access the hardware any more and I
>> doubt that anybody of sane mind would include some sort of device driver
>> (and yes, I have written a few of them in my time so I know what they can
>> do) with a browser simply to get better timer resolution for some flashing
>> eye candy.
>
> var x;
> for( x=0;x<1000;++x)
> document.write(+(new Date())+" ");
></script>
>
> or if you have a slow PC (like me) try
>
><SCRIPT TYPE="text/javascript">
> var x,y=new Array(1000);
>
> x=1000;
> while(--x)
> y[x]=+(new Date());
>
> x=1000;
> while(--x)
> document.write((+y[x])+' ');
>
></SCRIPT>
>
> In Linux (mozilla 1.7) this gives what appears to be milisecond precision,
> ie repeated resullts with the same value written before the result changes
> to the next number (without skipping any).
>
> eg.
>
> 1133665943413 1133665943413 1133665943413 1133665943414 1133665943414
> 1133665943414 1133665943414 1133665943414 1133665943414 1133665943414
> 1133665943414 1133665943414 1133665943414 1133665943414 1133665943415
> 1133665943415 1133665943415 1133665943415 1133665943415 1133665943415
> 1133665943415 1133665943415 1133665943415 1133665943415 1133665943415
> 1133665943416 1133665943416 1133665943416 1133665943416 1133665943416
> 1133665943416 1133665943416 1133665943416 1133665943416 1133665943416
> 1133665943416 1133665943417 1133665943417 1133665943417 1133665943417
>
>> I really don't need to pursue what some hyporthetical browser writer may in
>> theory do or not do. I have enough problems solving my bugs in the *real*
>> world :-)
>
however settimeout (etc) seems less reilable, I'm not sure what underlying
OS feature is used for this timekeeping.
here we have steps of one, two or more miliseconds in response to a 1
milisecond setTimeout.
1133667849259 1133667849260 1133667849262 1133667849263 1133667849264
1133667849265 1133667849266 1133667849268 1133667849269 1133667849270
1133667849272 1133667849482 1133667849484 1133667849486 1133667849487
1133667849488 1133667849489 1133667849491 1133667849492 1133667849493
1133667849494 1133667849495 1133667849501 1133667849509 1133667849517
1133667849529 1133667849545 1133667849561 1133667849581 1133667849601
1133667849617 1133667849633 1133667849649 1133667849665 1133667849681
1133667849697 1133667849713 1133667849725 1133667849737 1133667849749
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html;
charset=ISO-8859-1">
<TITLE>Java Script Test</TITLE>
<SCRIPT TYPE="text/javascript">
var x,y=new Array(100);
x=100;
function foo()
{ y[x--]=+(new Date());
if(x) setTimeout(foo,1);
else
{ var s='';
x=100;
while(--x)
s+=((+y[x])+' ');
document.write(s);
}
}
foo()
</SCRIPT>
</HEAD>
<BODY>
<p>please wait for 100 ticks</p>
<div id="out"> results </br></div>
</BODY>
</HTML>
> Bye.
> Jasen
--
Bye.
Jasen
Jasen Betts
>
>> JRS: In article <amiy1fx2g1r7.s...@40tude.net>, dated Thu,
>> 1 Dec 2005 01:49:32 local, seen in news:comp.lang.javascript, rf
>> <r...@invalid.com> posted :
>>>Dr John Stockton wrote:
>
> [timer resolution]
>
>>>> A browser writer *could* go further.
>>>
>>>But I severely doubt any of them do.
>>
>> Agreed.
>
> Fine, that is all we need to be aware of.
>
>> Evidently you do not know all that much about the PC architecture, and
>> have not read the references that I provided.
>
> To the contrary, I know a great deal about PC architecture, to way back
> before when there *were* PCs, just chips laying round on a breadboard, and
> yes, I have read a couple of the references and find them sadly lacking,
> for instance talking about the "DOS" clock for &deity;'s sake :-)
The dos clock (timer chip registers) could be read with microsecond precision
with a few lines of C. these give precision better than 1 microsecond.
> This *is* 2005 :-) You do *not* get to access the hardware any more and I
> doubt that anybody of sane mind would include some sort of device driver
> (and yes, I have written a few of them in my time so I know what they can
> do) with a browser simply to get better timer resolution for some flashing
> eye candy.
<script type="text/javascript">
eg.
> I really don't need to pursue what some hyporthetical browser writer may in
> theory do or not do. I have enough problems solving my bugs in the *real*
> world :-)
so how does your browser perform with this clock test.
Bye.
Jasen
Dr John Stockton
2005 03:24:22 local, seen in news:comp.lang.javascript, Jasen Betts
<ja...@free.net.nospam.nz> posted :
>
>In Linux (mozilla 1.7) this gives what appears to be milisecond precision,
>ie repeated resullts with the same value written before the result changes
>to the next number (without skipping any).
>
>eg.
>
>1133665943413 1133665943413 1133665943413 1133665943414 1133665943414
>1133665943414 1133665943414 1133665943414 1133665943414 1133665943414
Could you try & report, with that system,
<URL:http://www.merlyn.demon.co.uk/js-dates.htm#Ress>, please ? Repeat
a few times, and maybe increase the Loop Count.
Than I can safely make an entry like
??? Linux ? Moz1.7 1 1
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Dr John Stockton
2005 03:55:19 local, seen in news:comp.lang.javascript, Jasen Betts
<ja...@free.net.nospam.nz> posted :
>
>however settimeout (etc) seems less reilable, I'm not sure what underlying
>OS feature is used for this timekeeping.
>
>here we have steps of one, two or more miliseconds in response to a 1
>milisecond setTimeout.
>
>1133667849259 1133667849260 1133667849262 1133667849263 1133667849264
>1133667849265 1133667849266 1133667849268 1133667849269 1133667849270
>1133667849272 1133667849482 1133667849484 1133667849486 1133667849487
ISTM that there may be considerably more overhead in setting a timeout
and responding than in grabbing a date (in a form which the OS may very
well already be maintaining).
You could try setting a 10 or 11 millisecond timeout to see if the same
bias and scatter occurs.
I don't know whether
<URL:http://www.merlyn.demon.co.uk/js-date0.htm#TaI> will show anything
of interest.
--
Jasen Betts
> JRS: In article <1cf1.4392...@clunker.homenet>, dated Sun, 4 Dec
> 2005 03:24:22 local, seen in news:comp.lang.javascript, Jasen Betts
><ja...@free.net.nospam.nz> posted :
>>
>>In Linux (mozilla 1.7) this gives what appears to be milisecond precision,
>>ie repeated resullts with the same value written before the result changes
>>to the next number (without skipping any).
>>
>>eg.
>>
>>1133665943413 1133665943413 1133665943413 1133665943414 1133665943414
>>1133665943414 1133665943414 1133665943414 1133665943414 1133665943414
>
>
> Could you try & report, with that system,
> <URL:http://www.merlyn.demon.co.uk/js-dates.htm#Ress>, please ? Repeat
> a few times, and maybe increase the Loop Count.
>
> Than I can safely make an entry like
> ??? Linux ? Moz1.7 1 1
I get resolution 1.16xxx but I'm almost certain that's
because of other tasks running in the background
and the correct value should be 1.00 , it's just this slow PC...
Yesterday I got microsecond resolution from gettimeofday()
(an os call, in a C program so I expect mozilla uses the
same time source)
BTW.
that table appears to the right of the text rather than under it like
all the other tables.
Bye.
Jasen
Dr John Stockton
2005 09:10:17 local, seen in news:comp.lang.javascript, Jasen Betts
<ja...@free.net.nospam.nz> posted :
I don't see that the Numerical Resolution can be other than an integer,
unless the individual new Date().getTime() readings are non-integer -
which I thought was not allowed. The Updating Interval could be over-
estimated in a busy system.
Thanks.
>BTW.
>that table appears to the right of the text rather than under it like
>all the other tables.
Yes. Though there's only one other Table on the page, near the end.