Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Deleting a preloaded image from memory

Reply
Thread Tools

Deleting a preloaded image from memory

 
 
Bart Van der Donck
Guest
Posts: n/a
 
      05-23-2006
Thomas 'PointedEars' Lahn wrote:

> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>
> > The problem is I really need to achieve this in Firefox because I am
> > making an extension.

>
> There is no need for preloading in the first place.


I'm thinking in the same direction, yes.

To the original poster:
In stead of shoe-horning your way through browsers' internal memory
block allocation, why not use plain simple HTML code. It works for
everybody else's image galleries, so why not for you ? Sure, one could
say something for your preloading idea. The obvious benefit is that a
surfer doesn't need to wait for the new images. But the same actually
applies to any web page. Say you have a homepage with a language choice
English/Dutch, why wouldn't you already preload the next 2 pages ?

I think your scenario has more disadvantages than benefits. I'ld
counsel a plain HTML strategy if I were you.

--
Bart

 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      05-23-2006
Bart Van der Donck wrote:

> Thomas 'PointedEars' Lahn wrote:
>> (E-Mail Removed) wrote:
>> > The problem is I really need to achieve this in Firefox because I am

^^^^^^^
>> > making an extension.

^^^^^^^^^
>> There is no need for preloading in the first place.

>
> I'm thinking in the same direction, yes.
>
> To the original poster:
> In stead of shoe-horning your way through browsers' internal memory
> block allocation, why not use plain simple HTML code. It works for
> everybody else's image galleries, so why not for you ? Sure, one could
> say something for your preloading idea. The obvious benefit is that a
> surfer doesn't need to wait for the new images. But the same actually
> applies to any web page. Say you have a homepage with a language choice
> English/Dutch, why wouldn't you already preload the next 2 pages ?
>
> I think your scenario has more disadvantages than benefits. I'ld
> counsel a plain HTML strategy if I were you.


Full ACK for (X)HTML. The `link' element can facilitate preloading if
it is considered really necessary.

But: Am I missing something here, or wasn't a Firefox extension running
on the Gecko chrome, hence on _XUL_? I fail to find /any/ need for
preloading _local_ resources; computers are this fast. IMHO, preloading
is only for resources retrieved from the server, for later local use.
Especially, probably XUL has the means so that no Image object needs to
be used, that memory is freed when the object is no longer used and that
switching images works smoothly anyway.


PointedEars
--
Homer: I have changed the world. Now I know how it feels to be God!
Marge: Do you want turkey sausage or ham?
Homer: Thou shalt send me *two*, one of each kind.
(Santa's Little Helper [dog] and Snowball [cat] run away )
 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      05-23-2006
(E-Mail Removed) wrote:

> How can I really delete a preloaded image from memory/disk cache?


You can _not_. You cannot even be sure that an image resource was cached.

And why would you want to do that anyway? The cache is not your business.
If the resource in the cache is outdated, use cache control headers to tell
the UA that this is the case. If it is not outdated, then why delete it?
Maybe you are confusing cache (file resource) and heap (memory resource).
Script objects are stored on the heap, not in the cache. Deleting an
object on the cache does not free heap memory and vice-versa.

> [...]
> delete images[0]; //RAM is not freed here!


Then there is probably another reference to that object. But, how are you
trying to determine "RAM" usage?

> Should I call delete on all the references to the image object?


No, you only need to `delete' those that are not defined local.
(You have to cared about scoping before? Tough luck.)

> What about the other new Image objects, that get their src attribute
> set to the same url?


The `src' _property_ does not matter here.

var img1 = new Image(); img1.src = "foo";

and

var img2 = new Image(); img2.src = "foo";

are still two different Image objects that require memory each. They maybe
use the same cached resource, that is all. That said, using different
Image objects for the same image resource is simply BAD -- Broken As
Designed.


PointedEars
--
When you have eliminated all which is impossible, then
whatever remains, however improbable, must be the truth.
-- Sherlock Holmes in Sir Arthur Conan Doyle's
"The Blanched Soldier"
 
Reply With Quote
 
Bart Van der Donck
Guest
Posts: n/a
 
      05-24-2006
Thomas 'PointedEars' Lahn wrote:

> (E-Mail Removed) wrote:
> > but just change the address the pointer is referencing
> > (from address of the object to null = 0x0000000).

>
> Pure speculation.


That is no speculation - it's just how this works. The 0x0(0)(0)...
address is the null pointer by default. Its notation (e.g. 0x0000000)
just depends on 8, 16, 32, etc bit memory, but it always refers to null
as the "very first" pre-reserved memory address.

Setting a javascript variable to null is just re-referencing it from
its current block to the one that belongs to null. The browsers that I
tested do not compile this action with a pragma to empty the referenced
memory though (supposed the address is not used anywhere else anymore).

Yes, I was surprised about the results of my ealier CPU benchmarks in
MSIE&FF. I expected the memory addresses would be cleaned up quite fast
if there were no references to it anymore (even with low job priority).

--
Bart

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      05-24-2006
Bart Van der Donck wrote:
> Thomas 'PointedEars' Lahn wrote:
>> (E-Mail Removed) wrote:
>>> but just change the address the pointer is referencing
>>> (from address of the object to null = 0x0000000).

>>
>> Pure speculation.

>
> That is no speculation - it's just how this works. The 0x0(0)(0)...
> address is the null pointer by default. Its notation (e.g. 0x0000000)
> just depends on 8, 16, 32, etc bit memory, but it always refers to
> null as the "very first" pre-reserved memory address.
>
> Setting a javascript variable to null is just re-referencing it from
> its current block to the one that belongs to null. ...

<snip>

You appear to be confusing javascript with C or some other language.
Javascript has no 'pointer' data types, its Null value is a primitive
type (so does not even have to be a reference of any sort, just an
arbitrary internal value) and the mechanism employed internally is not
specified in the applicable language specification and almost certainly
is not consistent across implementations.

You are speculating, and even reading some open source implementations
and making statements about what they do is irrelevant to the issues of
javascript authoring as those observations could never be applied to
all language implementations.

Richard.

 
Reply With Quote
 
Bart Van der Donck
Guest
Posts: n/a
 
      05-24-2006
Thomas 'PointedEars' Lahn wrote:

> (E-Mail Removed) wrote:
> > [...]
> > delete images[0]; //RAM is not freed here!

>
> Then there is probably another reference to that object.


The whole point of this discussion is that the object is fully
dereferenced, but the address itself still remains available internally
as a memory block.

> But, how are you trying to determine "RAM" usage?


On WinXP: CTRL-ALT-Delete > tab 'Processes' > 'Memory use'. On Unix,
see the 'top' command.

> > Should I call delete on all the references to the image object?

>
> No, you only need to `delete' those that are not defined local.
> (You have to cared about scoping before? Tough luck.)


There is a chance scoping could help, but frankly I don't think so
(haven't tested).

--
Bart

 
Reply With Quote
 
Bart Van der Donck
Guest
Posts: n/a
 
      05-24-2006
Richard Cornford wrote:

> [...]
> You appear to be confusing javascript with C or some other language.


I'm not talking about javascript code. I'm talking about how a browser
compiles javascript code.

> Javascript has no 'pointer' data types


Indeed, not at the high javascript code level - but it does at the
browser's low compile level. These are just general basic computer
mechanisms. Every variable points (or 'references' if you like) to a
memory block address. That isn't visible at the surface in javascript,
but is definitely how it works internally. Referencing and memory
allocation take place when the browser compiles the javascript to
something the machine understands. That's why it's so difficult to
influence memory handling from within javascript.

> its Null value is a primitive


No, 'null' is a well defined address (must be) and its reference is
somewhere between 0x000 and 0x0000000000000 (BTW, null is not a value,
it's the "not-value" that is defined that way by 0x0...).

> type (so does not even have to be a reference of any sort, just an
> arbitrary internal value) and the mechanism employed internally is not
> specified in the applicable language specification and almost certainly
> is not consistent across implementations.


Any computer language works with memory allocation/release and
(de)referencing to those.

> You are speculating,


No, I am not

> and even reading some open source implementations
> and making statements about what they do is irrelevant to the issues of
> javascript authoring as those observations could never be applied to
> all language implementations.


You're right - this discussion is irrelevant to javascript authoring
itself.

--
Bart

 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      05-24-2006
Bart Van der Donck wrote:
> Richard Cornford wrote:
>
> > [...]
> > You appear to be confusing javascript with C or some other language.

>
> I'm not talking about javascript code. I'm talking about how
> a browser compiles javascript code.


Browsers are not the only software that executes javascript code, and
you don't know how it is done in 'a browser', or anywhere else, in
general. You can only examine how it is done in specific
implementations, and cannot validly generalise beyond that. When you
are thinking about this remember that there is at least one javascript
implementation written in javascript.

>> Javascript has no 'pointer' data types

>
> Indeed, not at the high javascript code level - but it does at the
> browser's low compile level.


Not necessarily. IceBrowser uses Rhino for its javascript engine, and
Rhino is written in Java, so has no pointers. If you insist on going
down through the layers you will end up at the machine code level,
where there are no 'pointers', only integers loaded into data and
address registers, etc.

> These are just general basic computer
> mechanisms. Every variable points (or 'references' if you like) to a
> memory block address.


A memory address, it is only conceptually a block when some (byte)
length information is also associated with the value.

> That isn't visible at the surface in javascript,
> but is definitely how it works internally.


Which may be no more useful a statement than observing that CPUs
execute machine code.

> Referencing and memory allocation take place when the
> browser compiles the javascript to
> something the machine understands.


Rhino does not compile javascript to something the machine understands,
it compiles it to something the JVM understands, and the JVM does the
next step.

> That's why it's so difficult to
> influence memory handling from within javascript.


The difficulty is because javascript uses automatic garbage collection,
which is not intended to be influenced by executing code.

>> its Null value is a primitive

>
> No, 'null' is a well defined address (must be)


No, in javascript Null (the value that is assigned with - x = null -)
is a primitive value, and may or may not have any association with a
memory address.

> and its reference is
> somewhere between 0x000 and 0x0000000000000


An address between zero and zero (not a very wide gap)?

> (BTW, null is not a value,
> it's the "not-value" that is defined that way by 0x0...).


Not in javascript. In javascript Null is a primitive type with a single
value. The nature of that value is not specified or important. It may
be entirely arbitrary, or borrowed from the implementation language.

>> type (so does not even have to be a reference of any sort, just an
>> arbitrary internal value) and the mechanism employed internally is not
>> specified in the applicable language specification and almost certainly
>> is not consistent across implementations.

>
> Any computer language works with memory allocation/release
> and (de)referencing to those.


Memory allocation is not part of machine code. The lowest level at
which memory allocation would be expected is at the level of the OS.
And once you get far enough up that the memory allocation has been
abstracted outside of your control it stops being part of the picture
again.

>> You are speculating,

>
> No, I am not


Oh yes you are. You just don't have access to the information necessary
to make these generalisations.

>> and even reading some open source implementations and
>> making statements about what they do is irrelevant to the issues of
>> javascript authoring as those observations could never be applied to
>> all language implementations.

>
> You're right - this discussion is irrelevant to javascript authoring
> itself.


So irrelevant to this group.

Richard.

 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      05-24-2006
Bart Van der Donck wrote:

> Thomas 'PointedEars' Lahn wrote:
>> (E-Mail Removed) wrote:
>> > [...]
>> > delete images[0]; //RAM is not freed here!

>>
>> Then there is probably another reference to that object.

>
> The whole point of this discussion is that the object is fully
> dereferenced, but the address itself still remains available
> internally as a memory block.


The OP did write about other references to that object, see the citation
below.

BTW: You should look up the meaning of "(to) dereference".

>> But, how are you trying to determine "RAM" usage?

>
> On WinXP: CTRL-ALT-Delete > tab 'Processes' > 'Memory use'. On Unix,
> see the 'top' command.


Don't patronize me. That question was intentionally directed to the OP.

And the programs you mentioned (that I was well aware of) display only
memory usage of the _browser process_. Especially for Firefox, this does
not bear any meaning regarding memory usage of the script engine and
memory allocated for script objects, due to its known memory leaks.

>> > Should I call delete on all the references to the image object?

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^
>> No, you only need to `delete' those that are not defined local.
>> (You have to cared about scoping before? Tough luck.)

>
> There is a chance scoping could help, but frankly I don't think so
> (haven't tested).


Again you have no proof (not even the slightest hint in form of a test
result) for your wild assumptions at all but you insist on them. Although
regarding this question, it is very clear from the language specification
that a locally defined object reference ceases to exist once the execution
context is left (unless it is part of a closure). However, no more
references to an object means that the object is marked for garbage
collection. And the SpiderMonkey engine used by Firefox does not have
IE's "circular reference" problem.


PointedEars
--
This above all: To thine own self be true.
-- William Shakespeare (1564-1616)
 
Reply With Quote
 
Bart Van der Donck
Guest
Posts: n/a
 
      05-24-2006
Richard Cornford wrote:

> [...]
> >> You are speculating,

> >
> > No, I am not

>
> Oh yes you are. You just don't have access to the information necessary
> to make these generalisations.


Maybe this will convince you. Say the following javascript code:

var aVar;

That was the declaration. The computer reserves a name 'aVar' for
future use, but this name does not refer to a memory address yet at
this point.

aVar = 5;

That was the assignment. 5 is converted (to keep things simple) to
binary numerical data (the notation with 1's and 0's). Suppose each
memory block consists of 8 bits, then the value would become 00000101
in this case. Then 00000101 is allocated to an address, let's say we
name the address ABC. A programmer actually instructs the ABC-address
to remember the value 00000101 for him, in case he would need it later.
This memory allocation is a physical (electronical/magnetic) thing
inside the hardware of your PC.

The variable aVar then gets assigned to memory address ABC. If we
dereference aVar, we don't need name ABC anymore and we could free that
address (that is, if it was not used by something else anymore), and
thus gaining memory space to create new addresses.

In old computer languages like Assembler, this whole process would need
to be done manually. Each memory address was a series of (physical)
bulbs in a computer room. Each byte (corresponding to 8 bits in my
example) went on and off depending on the value it stored at that
moment. 1 is on and 0 is off - which is basically still the only thing
a computer knows (boolean values). I guess that's why early computers
were always associated by flikkering lamps.

Since a few decades, the jobs of the flikkering lamps were taken over
by minimal chipsets in stead of bulbs, today they're even 0,001
millimeter chips or so in stead of 1 meter of bulbs. Thus the term
micro-computing and even the company MicroSoft (=software for computers
with micro-chips).

--
Bart

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cannot Insert Preloaded Background Image into TR, TD in IE vunet.us@gmail.com Javascript 3 05-08-2007 02:08 PM
How can I disable HP preloaded datamining? warf Computer Security 13 12-15-2006 06:08 PM
My preloaded images are not preloaded anymore when ... marc557@juno.com Javascript 1 11-25-2006 05:36 AM
Preloaded XP and Explorer problem. Andrew Computer Support 7 12-19-2004 08:29 PM
password field can't be preloaded Homa ASP .Net 2 10-21-2003 01:28 AM



Advertisments