Path: csiph.com!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!news.tele.dk!news.tele.dk!small.news.tele.dk!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <1908140.bfDClWI3Sb@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sat, 08 Sep 2012 14:21:02 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 7Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <1399593.26SQpm16Mm@PointedEars.de> <1704778.3LbdHo29L0@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 91 NNTP-Posting-Date: 08 Sep 2012 14:21:03 CEST NNTP-Posting-Host: ddd174c6.newsspool1.arcor-online.net X-Trace: DXC=57ZBk5C1aje[F<50eo:0knic==]BZ:afn4Fo<]lROoRankgeX?EC@@`KPeR?^YhTLgDZm8W4\YJNlR=i2=[N6Y6jgLn>?b02nZcZ^k`AEH0:`` X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:15798 Tim Streater wrote: > Thomas 'PointedEars' Lahn wrote: >> Tim Streater wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> Tim Streater wrote: >> >> > And each time you call your ajax function you'll get a new one. >> >> Which is not a bad thing. >> >> >> >> > AIUI, although my knowledge of closures is a bit limited, each one >> >> > will live forever unless you explicitly dump it when you've finished >> >> > with it. By setting it to null, it'll get garbage-collected >> >> > subsequently. >> > I leave that to the browser to worry about. >> IOW, you are incompetent enough to not care about your users. > > Fuck off. Why I am even talking to you? You were incompetent when I scorefiled you years ago and you have not changed a bit. See below. >> >> Wishful thinking. There is no guarantee that garbage collection will >> >> commence before all browser windows are closed. >> > >> > [snip] >> > >> >> > request = null; >> >> >> >> With regard to memory efficiency and probably even runtime efficiency, >> >> it is far better to reuse an existing XHR object once the request has >> >> been >> >> processed. See JSX:http.js [1] for example. >> > >> > No doubt, but I may have several such requests outstanding at any given >> > moment and have no desire to manage a set of XHR objects. >> >> So you would rather not manage them and let them waste memory, one by >> one, >> eating it up until the browser application exits, in the worst case. >> Where is the logic in that? > > They don't waste memory, they get garbage collected. When? *That* is the question you have to ask yourself, and the answer to that is: You *cannot* know. So be slow to create new objects. > If I didn't set them to null they certainly would waste memory. You have a serious misconception of how these implementations work and how garbage collection works, in general. Which is unsurprising given your statement on the top (and yet you still think you know what is going on?). If you are assigning `null' or any other non-reference value to a property, what you are doing is merely to reduce the number of references to an object. (Because, you know, an object can have, and usually will have, *several* references to it. References are values here.) If, and only if, the number of references to an object reaches zero, the object becomes eligible for garbage collection (that is, the memory it uses can be freed, to be used by other data). It can (but does not need to) be *marked* for garbage collection then. When garbage collection actually happens, the memory reserved for *marked* objects is freed. Not before. In the best case, garbage collection happens when cyclically, defined by a probability algorithm, the engine cleans up after itself. The medium case is that garbage collection happens only when the engine runs out of free memory. In the worst case, it happens only when the engine is terminated, which is when the browser process is terminated (i.e., all windows are closed). This is not a fantasy. There have been and still are badly designed Web applications using client-side scripting eating up memory until the browser and operating system became virtually unusable (driving the swap size to the extreme) because people were not aware of the objects and closures they created and the applications and browsers ran for a longer time. Bottom line: Creating objects in the current browser session reserves memory. Creating more objects reserves more memory. Reserving memory reduces free memory. Assigning `null' to a property that previously had as value a reference to an object does _not_ *immediately* free that memory. It certainly does _not_ *trigger* garbage collection. It merely *allows* for garbage collection, if, and only if, all conditions I mentioned above are met. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16