Handle Leaks with Microsoft.XMLDOM

Dr John Stockton · Nov 30, 2005

JRS: In article <[email protected]>
, dated Tue, 29 Nov 2005 23:16:32 local, seen in

news:comp.lang.javascript said:
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.

rf · Nov 30, 2005

Dr said:
JRS: In article <[email protected]>, dated Wed, 30
Nov 2005 01:27:40 local, seen in Richard

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

VK · Dec 1, 2005

Dr said:
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 · Dec 1, 2005

and naturally Date object itself cannot be more exact then one tick:

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 · Dec 1, 2005

VK said:
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.

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.

rf · Dec 1, 2005

VK said:
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

VK · Dec 1, 2005

rf said:
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" 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 · Dec 1, 2005

VK said:
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 · Dec 1, 2005

VK said:
<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.

Thomas 'PointedEars' Lahn · Dec 1, 2005

VK said:
<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.

... 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 · Dec 1, 2005

JRS: In article <[email protected]>, dated Thu,
1 Dec 2005 01:49:32 local, seen in rf

But I severely doubt any of them do.
Agreed.

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.

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

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.

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.

Dr John Stockton · Dec 1, 2005

JRS: In article <[email protected]>
, dated Thu, 1 Dec 2005 04:19:02 local, seen in

news:comp.lang.javascript said:
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.

rf · Dec 2, 2005

Dr said:
JRS: In article <[email protected]>, dated Thu,
1 Dec 2005 01:49:32 local, seen in rf

[timer resolution]

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

Martin Nedbal · Dec 3, 2005

Martin said:
t's strange to reply to one's own post, but - the problem is caused by
hotfix 896688, the only trouble is that it fixes quite a holes in
security

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.

Dr John Stockton · Dec 4, 2005

JRS: In article <[email protected]>, dated Sun, 4 Dec
2005 03:24:22 local, seen in Jasen Betts

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

Dr John Stockton · Dec 4, 2005

JRS: In article <[email protected]>, dated Sun, 4 Dec
2005 03:55:19 local, seen in Jasen Betts

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.

Dr John Stockton · Dec 6, 2005

JRS: In article <[email protected]>, dated Mon, 5 Dec
2005 09:10:17 local, seen in Jasen Betts

pc Linux 2.6.13.2 Mozilla 1.7.8 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)

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.

In Firefox null gets assigned before XHR returns. Works in IE.	9	Oct 13, 2009
In Firefox (2.0.0.18) .readyState hung at 3 while .responseText hasthe data but .responseXML is nul.	18	Nov 27, 2008
Passing querystring variable to function	3	Nov 30, 2007
need help with generic ajax get function	6	Apr 21, 2009
Script working in Firefox but not IE7	5	Sep 10, 2007
Help with JavaScript	4	Mar 28, 2008
? Trouble with: passing dragElement(e.target.id);	8	Jan 11, 2023
JS ajax request	15	Dec 5, 2008

Handle Leaks with Microsoft.XMLDOM

Dr John Stockton

rf

VK

VK

rf

rf

VK

VK

rf

Thomas 'PointedEars' Lahn

Dr John Stockton

Dr John Stockton

rf

Martin Nedbal

Dr John Stockton

Dr John Stockton

Dr John Stockton

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads