• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

js references/garbage collection/other questions

 
Ranch Hand
Posts: 429
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everyone, I have a few javascript questions:

1. Do javascript object references work similarly to Java object references?

For example:



Would each time that foo() gets called eat up more memory, or should the javascript engine notice the orphaned strings and primitives and free up the memory?

3. Finally, when declaring a local variable in a function, what is the difference between putting 'var' before the declaration vs. leaving it out?

Thank you in advance,
Yuriy
 
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry I have not gotten back sooner. I am busy with my book and have to stay away from the net so I get work done. LOL

Check out this link, it should give you a good understanding on how JavaScript handles memory. (BUT You do see memory links with DOM when you get very advanced)

Eric
 
Eric Pascarello
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
AH the link:
www.mozilla.org/scriptable/avoiding-leaks.html
 
Eric Pascarello
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh for #3, a simple script can explain why you need to use var inside a function.

[code]
<script type="text/javascript">

var test1 ="1";

function Test(){
var test2 = "2";
test3 = "3";
alert("In Function\n\ntest1: " + typeof(test1) +"\ntest2: " + typeof(test2) +"\ntest3: " + typeof(test3));
}

window.onload = function(){
alert("Load\n\ntest1: " + typeof(test1) +"\ntest2: " + typeof(test2) +"\ntest3: " + typeof(test3));
Test();
alert("After Call\n\ntest1: " + typeof(test1) +"\ntest2: " + typeof(test2) +"\ntest3: " + typeof(test3));

}

</script>
[code]

Eric
 
Yuriy Zilbergleyt
Ranch Hand
Posts: 429
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Eric!

The script demonstrate the differences very simply, but I'm having a little trouble making full sense the Mozilla link.

1. This refers to just Mozilla's implementation of javascript, right? So something that causes leaks for Mozilla browsers might be safe for IE, and vice versa?

2. I understand that doing something like "myDiv.oref = new Array()" means the array can't be garbage collected as long as myDiv exists. But the headline "Don't store short-lived objects as JavaScript properties of short-lived DOM nodes" seems to imply that even if myDiv goes away (through either changing it's parent's innerHTML property or calling one of the removeNode() like methods), the array will be immunge to garbage collection?


I think it's best to give a brief overview of the project I'm working on and the strategies we're planning on using. At least I'll try to be brief. None of us are experts at Javascript, we've sort of been learning as we go.

The project is an intranet-only web-app for a specific customer. It is manadory that we support IE6.0, and while Firefox support would be nice, it's not part of the requirements.

The application is a "Contract Viewer." A user types in a contract number and sees the information regarding that Contract (retrieved from a database/repository.) There is a LOT of information there, so the contract view will have a collapsible tree-style navigation on the left, and "content view" on the right. Depending on what's selected from the navigation, the content view will either show a PDF document(inside an iframe) or tables and other information retrieved using XMLHttpRequest.

The user will be able to have multiple contracts open on the same page. Information regarding only a single contract will be viewable at a time, and the contracts will be switched between using "tabs". When a user opens a contract for the first time (during that session, on that page), XMLHttpRequest is used to get the HTML (navigation and the default content view) for that contract from the server. If there are no errors, a new "tab" is created on the page, and the contract is displayed by the setting of a DIV's innerHTML property to the retrieved HTML.

Now comes the question of how to keep track of the multiple contracts that a user has opened. We want to avoid going to the server every time the user switches between the already opened contracts by clicking on the different contract tabs. One solution would be to store each contract view in a seperate DIV element, and hide the DIVs for all non-selected contract tabs. The problem is that this would result in a HUGE Dom tree.

What we're planning to do is to have only a single DIV element for the contract data, and a javascript Array containing the innerHTMLs of every contract that's not being displayed. When a user is viewing a contract and opens a new one, the innerHTML of the contract DIV get's backed up in the Contracts Array, indexed by the currently displayed contract's number. Then the innerHTML gets replaced by the responseText of the XMLHttpRequest (new contract data). When a user clicks on a tab of a previously viewed contract, the DIV's innerHTML again gets backed up in the array, and is replaced by the innerHTML data that was stored in the array before.

This way instead of having a huge Dom tree for a page "displaying" multiple contracts, we have a huge javascript array. Actually each contract will have multiple possible "content views", selected from the navigation, which will act the same way - a user selects a certain view, XMLHttpRequest returns the HTML, the current view's innerHTML get's backed up in the contract's own array, and so on. So every entry in the big Contracts array will be a single Contract Array/object which will have the backed up innerHTML for the contract DIV, as well as the backed up innerHTMLs for each previously displayed content view for that contract.

The current plan is to only allow the user to have 6 contract's per page. If they want more, they will have the option to close one of the contract tabs. When a contract tab is closed, that contract's entry in the Contracts Array is set to null (ContractsArray[contractNumber] = null), which we hope will free up all the memory taken up by that contract's data.

I'm sorry if this is confusing, but I'm sure you can see why I'm worried about memory leaks with this setup. I know that most of these issues would be dealt with by only storing one contract's data in the page at a time and going to the server whenever a user clicks on a different contract tab, but we are trying to avoid it for server performance reasons. Plus we don't want the user's actions while on a contract's view (which navigation and content tree branches are expanded, which content view is selected) to be wiped during the switch, and keeping track of all that between requests would be a nightmare.

Thank you,
Yuriy

P.S. Good luck with your book! I'll be sure to get it when it comes out. And of course I understand that it takes priority
[ June 29, 2005: Message edited by: Yuriy Zilbergleyt ]
 
A day job? In an office? My worst nightmare! Comfort me tiny ad!
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
reply
    Bookmark Topic Watch Topic
  • New Topic