467,144 Members | 1,165 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,144 developers. It's quick & easy.

Netscape 7.1 memory leaks

It seems that garbage collection is somewhat flawed in Netscape as the
following little script can bring a machine to its knees in about an
hour when run on Netstcape 7.1. I've tried freeing the variables
manually, but Im not sure whats broken. I assume that the images
aren't being freed when they are replaced. Is there a
workaround/solution to this? I've read some old postings about this in
4.x browsers, but I never saw a solution, and its apparently still not
been repaired.

Dennis

<html>
<head>
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date();

return date.getTime();
}
function loadIT()
{
myimage=new Image;

myimage.src="someimage.jpg?rand=" + randgen();
setTimeout("loadIT()",1000);
}
loadIT();
</script>
</head>
<body>
</body>
</html>
Jul 23 '05 #1
  • viewed: 1347
Share:
18 Replies
In article <3b*************************@posting.google.com> ,
de****@etinc.com enlightened us with...
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date();
You keep making a new date. Why not reuse the same one?
Little scripts, this isn't an issue, but if it runs a lot, eventually
you'll run out of memory.

return date.getTime();
}
function loadIT()
{
myimage=new Image;


Same as above.

/old C programmer

--
--
~kaeli~
What if the Hokey Pokey IS what's it's all about?
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #2
> setTimeout("loadIT()",1000);

I beleive this is your problem. You have the loadIT() method call in
quotation marks so basically it is just a meaningless string. To actually
call the method the JavaScript engine will wrap the string in an annonymous
function everytime this line of code is called.

This new annonymous function is added to the window object. Hence the memory
consuption problem, because the life of the annonymous function is equal to
the life of the window object.

The Date object creation is not a problem becuase it's life span is much
shorter, basically just the life of the method call that creates it.

To fix this problem simply rewrite that line of code to be

setTimeout(loadIT,1000);

Now instead of a meanlingless string, you are passing a function handle
which the method simple executes without adding any new objects into memory.

Hope this helps
Mike
Jul 23 '05 #3
Mike wrote:
setTimeout("loadIT()",1000);
I beleive this is your problem. You have the loadIT() method call in
quotation marks so basically it is just a meaningless string. To
actually call the method the JavaScript engine will wrap the string
in an annonymous function everytime this line of code is called.


setTimeout has supported strings as its first argument longer than it
has supported function references as its first argument (and so in more
browsers). It is unlikely that setTimeout would create a function object
in order to execute the string, it would only be necessary to pass it on
to the - eval - function in order to have it executed.
This new annonymous function is added to the window object.
Even if an anonymous function object was created for the execution of a
string argument to setTimeout there is no reason to expect it to be
added to the window object (and if it was added what property name would
be used?).
Hence the
memory consuption problem, because the life of the annonymous
function is equal to the life of the window object.
The continuous creation of Image objects is more likely the source of
the memory leak (assuming that there is one, as no demonstration of the
phenomenon has been provided).
The Date object creation is not a problem becuase it's life span is
much shorter, basically just the life of the method call that creates
it.

To fix this problem simply rewrite that line of code to be

setTimeout(loadIT,1000);

Now instead of a meanlingless string, ...

<snip>

That string was never meaningless, it is valid javascript source code,
as should be provided when a string argument is used with setTimout.

Richard.
Jul 23 '05 #4
Richard Cornford wrote:
Mike wrote:
setTimeout("loadIT()",1000);
I beleive this is your problem. You have the loadIT() method call in
quotation marks so basically it is just a meaningless string. To
actually call the method the JavaScript engine will wrap the string
in an annonymous function everytime this line of code is called.

setTimeout has supported strings as its first argument longer than it
has supported function references as its first argument (and so in more
browsers). It is unlikely that setTimeout would create a function object
in order to execute the string, it would only be necessary to pass it on
to the - eval - function in order to have it executed.

This new annonymous function is added to the window object.

Even if an anonymous function object was created for the execution of a
string argument to setTimeout there is no reason to expect it to be
added to the window object (and if it was added what property name would
be used?).


This is correct. Spidermonkey (the JS engine in Netscape/Mozilla) will
create function objects as it would an integer or date. All objects are
JSObject types, regardless of being a function, a string, a date, or a
custom type. All objects are subject to garbage collection.
Hence the
memory consuption problem, because the life of the annonymous
function is equal to the life of the window object.

The continuous creation of Image objects is more likely the source of
the memory leak (assuming that there is one, as no demonstration of the
phenomenon has been provided).


It seems like the image objects would be garbage collected as well, but
there could be a cache thing going on. How big is the cache set to? (I
am not sure if this matters or not). Since each Image object is
associated with a cache entry (each image is randomly generated), it
could be rooting the image objects in the Spidermonkey engine.

OP: Does it exhibit this behavior when the cache is lower? How about
when it is turned off?

Can you point us to a link that causes this to happen? Does this happen
in any other browsers? (IE, Safari, Opera, etc)

Just some ideas,
Brian

Jul 23 '05 #5
Brian Genisio wrote:
<snip>
... . Spidermonkey (the JS engine in Netscape/Mozilla)
will create function objects as it would an integer or date.
All objects are JSObject types, regardless of being a function,
a string, a date, or a custom type. ...

<snip>

If code provided to setTimout as a string argument was executed in an
anonymous function then an - arguments - object would be available to
it. A quick test of:-

setTimeout('alert(typeof arguments);',100);

setTimeout(function(){alert(typeof arguments);},100);

Suggests that the code provided as a string argument is not executed in
an anonymous function on Mozilla browsers.

Richard.
Jul 23 '05 #6
Richard Cornford wrote:
Brian Genisio wrote:
<snip>
... . Spidermonkey (the JS engine in Netscape/Mozilla)
will create function objects as it would an integer or date.
All objects are JSObject types, regardless of being a function,
a string, a date, or a custom type. ...


<snip>

If code provided to setTimout as a string argument was executed in an
anonymous function then an - arguments - object would be available to
it. A quick test of:-

setTimeout('alert(typeof arguments);',100);

setTimeout(function(){alert(typeof arguments);},100);

Suggests that the code provided as a string argument is not executed in
an anonymous function on Mozilla browsers.

Richard.


Yeah, sorry, I was not completely clear in what I was saying. I was
saying "If a function object is being created..." in response to your
"Even if an anonymous function object was created for the execution..."
statement. I was making no assumptions about the way setTimeout (or
other similar functions) executes the code, only working off the
prefaced assumption that it does create an anonymous function object.

In reality, I was agreeing completely with what you were saying, by
backing it up with my understanding of the NS JS engine :)

Have a day!
Brian

Jul 23 '05 #7
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:<c6*******************@news.demon.co.uk>...
Brian Genisio wrote:
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date(); You keep making a new date. Why not reuse the same one?
Little scripts, this isn't an issue, but if it runs a lot, eventually
you'll run out of memory.
Well if I dont get a "new date" is ceases to do with the function is
intended to do. Its a local variable, so I would think that garbage
collection would have no problem disposing of local variables.
<snip>
... . Spidermonkey (the JS engine in Netscape/Mozilla)
will create function objects as it would an integer or date.
All objects are JSObject types, regardless of being a function,
a string, a date, or a custom type. ...

<snip>

If code provided to setTimout as a string argument was executed in an
anonymous function then an - arguments - object would be available to
it. A quick test of:-

setTimeout('alert(typeof arguments);',100);

setTimeout(function(){alert(typeof arguments);},100);


Given all of this philosophical banter, I've tested it both ways and
it makes no difference in terms of lost memory. In fact I think I've
tested every variation of "normal" code possible, which is why I
originally concluded that the problem had to do with the ".src" object
not being freed when it is replaced. Assuming Im correct, any ideas on
how to explicitly free the image object before replacing it? "new"
should free the old one, I would think. I've also tried:

myImage = new Image;

function()
{
myImage.src=null;
myImage.src="whatever";
}
with the same memory loss. Its quite baffling. I dont know if I
mentioned it, but ALL of these variations show NO memory loss in IE,
no matter how badly I code it (just so someone says something nice
about MS once in a while :-)

Dennis
Jul 23 '05 #8
Dennis wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:<c6*******************@news.demon.co.uk>...
Brian Genisio wrote:
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date();


You keep making a new date. Why not reuse the same one?
Little scripts, this isn't an issue, but if it runs a lot, eventually
you'll run out of memory.

Well if I dont get a "new date" is ceases to do with the function is
intended to do. Its a local variable, so I would think that garbage
collection would have no problem disposing of local variables.

<snip>
... . Spidermonkey (the JS engine in Netscape/Mozilla)
will create function objects as it would an integer or date.
All objects are JSObject types, regardless of being a function,
a string, a date, or a custom type. ...


<snip>

If code provided to setTimout as a string argument was executed in an
anonymous function then an - arguments - object would be available to
it. A quick test of:-

setTimeout('alert(typeof arguments);',100);

setTimeout(function(){alert(typeof arguments);},100);

Given all of this philosophical banter, I've tested it both ways and
it makes no difference in terms of lost memory. In fact I think I've
tested every variation of "normal" code possible, which is why I
originally concluded that the problem had to do with the ".src" object
not being freed when it is replaced. Assuming Im correct, any ideas on
how to explicitly free the image object before replacing it? "new"
should free the old one, I would think. I've also tried:

myImage = new Image;

function()
{
myImage.src=null;
myImage.src="whatever";
}
with the same memory loss. Its quite baffling. I dont know if I
mentioned it, but ALL of these variations show NO memory loss in IE,
no matter how badly I code it (just so someone says something nice
about MS once in a while :-)

Dennis


What about the cache thing that I mentioned?

I dont know if I would call what you are experiencing a memory leak. A
memory leak is where memory continues to grow, and the program looses
track of it. I am guessing that Netscape has not lost track of the
memory, but is just holding on to it instead.

You might try asking this question in:
netscape.public.mozilla.dom
netscape.public.mozilla.jseng

Your question might be slightly off topic in both of those groups, but
the people there might have the knowledge to help.

Brian
Jul 23 '05 #9
Brian Genisio <Br**********@yahoo.com> wrote in message news:<40********@10.10.0.241>...
Dennis wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:<c6*******************@news.demon.co.uk>...
Brian Genisio wrote:
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date();


You keep making a new date. Why not reuse the same one?
Little scripts, this isn't an issue, but if it runs a lot, eventually
you'll run out of memory.

Well if I dont get a "new date" is ceases to do with the function is
intended to do. Its a local variable, so I would think that garbage
collection would have no problem disposing of local variables.

<snip>

... . Spidermonkey (the JS engine in Netscape/Mozilla)
will create function objects as it would an integer or date.
All objects are JSObject types, regardless of being a function,
a string, a date, or a custom type. ...

<snip>

If code provided to setTimout as a string argument was executed in an
anonymous function then an - arguments - object would be available to
it. A quick test of:-

setTimeout('alert(typeof arguments);',100);

setTimeout(function(){alert(typeof arguments);},100);

Given all of this philosophical banter, I've tested it both ways and
it makes no difference in terms of lost memory. In fact I think I've
tested every variation of "normal" code possible, which is why I
originally concluded that the problem had to do with the ".src" object
not being freed when it is replaced. Assuming Im correct, any ideas on
how to explicitly free the image object before replacing it? "new"
should free the old one, I would think. I've also tried:

myImage = new Image;

function()
{
myImage.src=null;
myImage.src="whatever";
}
with the same memory loss. Its quite baffling. I dont know if I
mentioned it, but ALL of these variations show NO memory loss in IE,
no matter how badly I code it (just so someone says something nice
about MS once in a while :-)

Dennis


What about the cache thing that I mentioned?

I dont know if I would call what you are experiencing a memory leak. A
memory leak is where memory continues to grow, and the program looses
track of it. I am guessing that Netscape has not lost track of the
memory, but is just holding on to it instead.

You might try asking this question in:
netscape.public.mozilla.dom
netscape.public.mozilla.jseng

Your question might be slightly off topic in both of those groups, but
the people there might have the knowledge to help.

Brian

Since it "holds onto it" until the browser is closed (and the OS has
to do it), I think it would qualify as a leak. There's too many bugs
in Mozilla to bother reporting such things, and you'll lose more
customers telling people to upgrade their buggy netscape browsers than
you will telling them to fire up IE in the long run anyway.
Jul 23 '05 #10
Dennis wrote:
Brian Genisio <Br**********@yahoo.com> wrote in message news:<40********@10.10.0.241>...
Dennis wrote:

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:<c6*******************@news.demon.co.uk>...
Brian Genisio wrote:
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date();
You keep making a new date. Why not reuse the same one?
Little scripts, this isn't an issue, but if it runs a lot, eventually
you'll run out of memory.
Well if I dont get a "new date" is ceases to do with the function is
intended to do. Its a local variable, so I would think that garbage
collection would have no problem disposing of local variables.

<snip>

>... . Spidermonkey (the JS engine in Netscape/Mozilla)
>will create function objects as it would an integer or date.
>All objects are JSObject types, regardless of being a function,
>a string, a date, or a custom type. ...

<snip>

If code provided to setTimout as a string argument was executed in an
anonymous function then an - arguments - object would be available to
it. A quick test of:-

setTimeout('alert(typeof arguments);',100);

setTimeout(function(){alert(typeof arguments);},100);

Given all of this philosophical banter, I've tested it both ways and
it makes no difference in terms of lost memory. In fact I think I've
tested every variation of "normal" code possible, which is why I
originally concluded that the problem had to do with the ".src" object
not being freed when it is replaced. Assuming Im correct, any ideas on
how to explicitly free the image object before replacing it? "new"
should free the old one, I would think. I've also tried:

myImage = new Image;

function()
{
myImage.src=null;
myImage.src="whatever";
}
with the same memory loss. Its quite baffling. I dont know if I
mentioned it, but ALL of these variations show NO memory loss in IE,
no matter how badly I code it (just so someone says something nice
about MS once in a while :-)

Dennis


What about the cache thing that I mentioned?

I dont know if I would call what you are experiencing a memory leak. A
memory leak is where memory continues to grow, and the program looses
track of it. I am guessing that Netscape has not lost track of the
memory, but is just holding on to it instead.

You might try asking this question in:
netscape.public.mozilla.dom
netscape.public.mozilla.jseng

Your question might be slightly off topic in both of those groups, but
the people there might have the knowledge to help.

Brian


Since it "holds onto it" until the browser is closed (and the OS has
to do it), I think it would qualify as a leak. There's too many bugs
in Mozilla to bother reporting such things, and you'll lose more
customers telling people to upgrade their buggy netscape browsers than
you will telling them to fire up IE in the long run anyway.


Ok, I didnt realize that it held on to the images until the browser was
closed. Are you sure it is not re-using the memory? They may have a
memory manager that takes what it needs, and frees it logically, but not
to the OS. This way, it can use it for other pages. Either way, if it
continues to grow, there is obviously a problem. Too bad no one here
can help. I know I cant think of anything else.

Did you try the netscape groups I mentioned? These are public groups,
with some netscape developers. They my know of work-arounds.

Brian

Jul 23 '05 #11
Dennis wrote:
It seems that garbage collection is somewhat flawed in Netscape as the
following little script can bring a machine to its knees in about an
hour when run on Netstcape 7.1. I've tried freeing the variables
manually, but Im not sure whats broken. I assume that the images
aren't being freed when they are replaced. Is there a
workaround/solution to this? I've read some old postings about this in
4.x browsers, but I never saw a solution, and its apparently still not
been repaired.

Dennis

<html>
<head>
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date();

return date.getTime();
}
function loadIT()
{
myimage=new Image;

myimage.src="someimage.jpg?rand=" + randgen();
setTimeout("loadIT()",1000);
}
loadIT();
</script>
</head>
<body>
</body>
</html>


Garbage collection is a low-priority task. You're creating new objects at
the rate of one a second over an hour. Netscape probably never bothers to
do any garbage collection until the browser is more "idle" then you are
allowing it to be at any point during the execution. As a result it just
continues to request memory from the operating system (which the operating
system is happy to provide up to and beyond the amount of physical memory
present on the system). Once you exceed the amount of physical memory
available, the operating system will begin to swap and you will have
serious performance problems.

Do you really want everyone using that page to be making requests to your
Web server every second? Since you never display the image I'm guessing
you're using it as some sort of "keep alive" session management or
something? HTTP through a Web browser isn't really the proper medium for
something that requires knowing if the client is connected every second.
You're trying to drive a nail with a screwdriver.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html
Jul 23 '05 #12
Grant Wagner <gw*****@agricoreunited.com> wrote in message news:<40***************@agricoreunited.com>...
Dennis wrote:
It seems that garbage collection is somewhat flawed in Netscape as the
following little script can bring a machine to its knees in about an
hour when run on Netstcape 7.1. I've tried freeing the variables
manually, but Im not sure whats broken. I assume that the images
aren't being freed when they are replaced. Is there a
workaround/solution to this? I've read some old postings about this in
4.x browsers, but I never saw a solution, and its apparently still not
been repaired.

Dennis

<html>
<head>
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date();

return date.getTime();
}
function loadIT()
{
myimage=new Image;

myimage.src="someimage.jpg?rand=" + randgen();
setTimeout("loadIT()",1000);
}
loadIT();
</script>
</head>
<body>
</body>
</html>


Garbage collection is a low-priority task. You're creating new objects at
the rate of one a second over an hour. Netscape probably never bothers to
do any garbage collection until the browser is more "idle" then you are
allowing it to be at any point during the execution. As a result it just
continues to request memory from the operating system (which the operating
system is happy to provide up to and beyond the amount of physical memory
present on the system). Once you exceed the amount of physical memory
available, the operating system will begin to swap and you will have
serious performance problems.

Do you really want everyone using that page to be making requests to your
Web server every second? Since you never display the image I'm guessing
you're using it as some sort of "keep alive" session management or
something? HTTP through a Web browser isn't really the proper medium for
something that requires knowing if the client is connected every second.
You're trying to drive a nail with a screwdriver.

--
| Grant Wagner <gw*****@agricoreunited.com>


the example provided is designed to accelerate the problem so it
happens in a half hour rather than a day.

Being able to "drive a nail with a screwdriver" has earned me a pretty
good living, and its what sets apart the men from the boys in the
programming field. Bad programmers make excuses; Good programmers find
solutions.

Your management or customers aren't going to care how you got
something done, only that the end result works well, is intuitive and
doesnt cause a 2Ghz machine to run like an IBM XT (ie Java). It helps,
of course, when the tools work as expected.

Dennis
Jul 23 '05 #13
Dennis wrote:
Garbage collection is a low-priority task. You're creating new objects at
the rate of one a second over an hour. Netscape probably never bothers to
do any garbage collection until the browser is more "idle" then you are
allowing it to be at any point during the execution. As a result it just
continues to request memory from the operating system (which the operating
system is happy to provide up to and beyond the amount of physical memory
present on the system). Once you exceed the amount of physical memory
available, the operating system will begin to swap and you will have
serious performance problems.

Do you really want everyone using that page to be making requests to your
Web server every second? Since you never display the image I'm guessing
you're using it as some sort of "keep alive" session management or
something? HTTP through a Web browser isn't really the proper medium for
something that requires knowing if the client is connected every second.
You're trying to drive a nail with a screwdriver.
the example provided is designed to accelerate the problem so it
happens in a half hour rather than a day.

Being able to "drive a nail with a screwdriver" has earned me a pretty
good living, and its what sets apart the men from the boys in the
programming field. Bad programmers make excuses; Good programmers find
solutions.


And shysters use unreliable hacks to achieve a result until their hack comes unglued, then they blame their
tools.
Your management or customers aren't going to care how you got
something done, only that the end result works well, is intuitive and
doesnt cause a 2Ghz machine to run like an IBM XT (ie Java). It helps,
of course, when the tools work as expected.


They also expect it to work long-term and not break with the latest release of the latest "gee whiz" browser.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
* http://devedge.netscape.com/library/...ce/frames.html
* Internet Explorer DOM Reference available at:
* http://msdn.microsoft.com/workshop/a...ence_entry.asp
* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html
Jul 23 '05 #14
Grant Wagner <gw*****@agricoreunited.com> wrote in message news:<40***************@agricoreunited.com>...
Dennis wrote:
Garbage collection is a low-priority task. You're creating new objects at
the rate of one a second over an hour. Netscape probably never bothers to
do any garbage collection until the browser is more "idle" then you are
allowing it to be at any point during the execution. As a result it just
continues to request memory from the operating system (which the operating
system is happy to provide up to and beyond the amount of physical memory
present on the system). Once you exceed the amount of physical memory
available, the operating system will begin to swap and you will have
serious performance problems.

Do you really want everyone using that page to be making requests to your
Web server every second? Since you never display the image I'm guessing
you're using it as some sort of "keep alive" session management or
something? HTTP through a Web browser isn't really the proper medium for
something that requires knowing if the client is connected every second.
You're trying to drive a nail with a screwdriver.


the example provided is designed to accelerate the problem so it
happens in a half hour rather than a day.

Being able to "drive a nail with a screwdriver" has earned me a pretty
good living, and its what sets apart the men from the boys in the
programming field. Bad programmers make excuses; Good programmers find
solutions.


And shysters use unreliable hacks to achieve a result until their hack comes unglued, then they blame their
tools.
Your management or customers aren't going to care how you got
something done, only that the end result works well, is intuitive and
doesnt cause a 2Ghz machine to run like an IBM XT (ie Java). It helps,
of course, when the tools work as expected.


They also expect it to work long-term and not break with the latest release of the latest "gee whiz" browser.


I would say that sabotaging a design that will work on 95% of machines
to accommodate those stupid enough to use "gee-whiz" browsers is the
one whos making the mistake. If you'd rather stand by your square
wheel and pound your chest that it "fits any car" good for you, but my
round wheel is going to blow yours away. Product design is about
making money; about having a better product, not about making
universally mediocre widgets.

You really dont have a point because Im not trying to do anything out
of spec. Nor am I trying to drive a nail with a screwdriver. Netscape
just has a plethora of problems, as they always have. We all know it,
so why are you agruing against it?
Jul 23 '05 #15
Mike wrote:

Who wrote this? <http://netmeister.org/news/learn2quote.html>
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
setTimeout("loadIT()",1000);


I beleive this is your problem. You have the loadIT() method call in
quotation marks so basically it is just a meaningless string. [...]


This is utter nonsense. All known implementations of setTimeout() accept a
string as first argument, since they have been implemented, to evaluate that
string after the specified timeout (here: 1s). If you would bothered to
read and understand the discussions we had the last days, you would not have
needed to demonstrate your pseudo-knowledge.

Besides, does Charles Newman know that you are abusing his domain by
violating Internet/NetNets standards (RFC 2822: "A mailbox receives
mail.")?
PointedEars
Jul 23 '05 #16
Dennis wrote:
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:<c6*******************@news.demon.co.uk>...


Please do not (let your software) write attribution novels.
Brian Genisio wrote:
<script language="JavaScript">
var myimage;

function randgen()
{
var date = new Date();

You keep making a new date. Why not reuse the same one?
Little scripts, this isn't an issue, but if it runs a lot, eventually
you'll run out of memory.


Well if I dont get a "new date" is ceases to do with the function is
intended to do. Its a local variable, so I would think that garbage
collection would have no problem disposing of local variables.


One solution may be to assign `null' after the last reference to `date'.
It is a way to "ask" the GC for reference evaluation (i.e. if there is
no reference to the object anymore, it is GC'd).

Since the local `date' is only used in

| return date.getTime();

another solution could be

return new Date().getTime();

And no additional function would be required then, since randgen() is only
used in

| myimage.src="someimage.jpg?rand=" + randgen();

which can be rewritten as

myimage.src = "someimage.jpg?rand=" + new Date().getTime();
BTW: Brian, Dennis, would the two of you please trim your future quotes to
the absolute necessary? See <http://netmeister.org/news/learn2quote.html>.
Thanks in advance.
PointedEars
Jul 23 '05 #17
Thomas 'PointedEars' Lahn wrote:
BTW: Brian, Dennis, would the two of you please trim your future quotes to
the absolute necessary? See <http://netmeister.org/news/learn2quote.html>.
Thanks in advance.


Brian, Dennis, ignore him. Puberty is coming and he cant help himself.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/
Jul 23 '05 #18
Dennis wrote:
I would say that sabotaging a design that will work on 95% of machines
to accommodate those stupid enough to use "gee-whiz" browsers is the
one whos making the mistake. If you'd rather stand by your square
wheel and pound your chest that it "fits any car" good for you, but my
round wheel is going to blow yours away. Product design is about
making money; about having a better product, not about making
universally mediocre widgets.
I'm not talking about sabotaging anything. I'm talking about fixing a design that isn't working in one of the
browsers in that 5% you think is unimportant. But as I've said before, when all you've got is a screwdriver,
everything looks like a nail, so pound away.
You really dont have a point because Im not trying to do anything out
of spec. Nor am I trying to drive a nail with a screwdriver. Netscape
just has a plethora of problems, as they always have. We all know it,
so why are you agruing against it?


Because using client-side code to request an image with random number attached to the end of the URI is leading to
problems, whereas:

<iframe id="session" src="<%= addSessionInfo('session.jsp') %>" width="1" height="1"
style="visibility:hidden;"></iframe>
<ilayer id="sessionNS4" src="<%= addSessionInfo('sessionNS4.jsp') %>" width="1" height="1"
style="display:none;"></ilayer>

-- session.jsp:

<html>
<head>
<meta http-equiv="refresh" content="900; URL=<%= addSessionInfo('session.jsp') %>" />
</head>
<body>
</body>
</html>

-- sessionNS4.jsp:

<html>
<head>
</head>
<body onload="if (document.layers) var t = setTimeout('document.layers[\'sessionNS4\'].src = \'<%=
addSessionInfo('sessionNS4.jsp') %>\'', 900000);">
</body>
</html>

while still relying on client-side technology for the Netscape 4 version, leads to no problems like you describe in
any of: Opera 7.23, IE5.5+, any of the recent Gecko browsers or Netscape 4.7x.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
* http://devedge.netscape.com/library/...ce/frames.html
* Internet Explorer DOM Reference available at:
* http://msdn.microsoft.com/workshop/a...ence_entry.asp
* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html
Jul 23 '05 #19

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Maurice | last post: by
reply views Thread by Steve Binney | last post: by
4 posts views Thread by Morten Aune Lyrstad | last post: by
2 posts views Thread by Generic Usenet Account | last post: by
8 posts views Thread by ranjeet.gupta@gmail.com | last post: by
4 posts views Thread by ali.jan@gmail.com | last post: by
23 posts views Thread by James | last post: by
3 posts views Thread by Jim Land | last post: by
16 posts views Thread by graham.keellings@gmail.com | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.