So the short answer is trial and error + process of elimination. Damn,
I was hoping there was a magical solution. :)
I might look into switching to Aptana if it has JSLint built in. I used
Eclipse exclusively when doing Java but haven't tried it on PHP and
_javascript_ for a long time, I guess the tools have matured quite a bit
by now.
Are the Prototype and SAU devs interested in making these libraries
JSLint validated? I know it would take a lot of work on the front end
and it doesn't like some of the uber-cool code shortcuts that we all
like to use, but once they're validated, I think it can help to avoid
these types of issues in the future and keeping it validated would be
very easy. I made all of my own libraries JSLint validated and it took
only a few hours using the extremely tedious online validator
copy/paste method...
Does Aptana highlight JSLint problems real-time like Eclipse does for
Java compiler warnings/errors? That would make the process quite
painless.
Thanks,
Colin
Malard wrote:
I used a combination of things to isolate it, first i tried using a
tool from Software Verify. That really did'nt help much. Although it
did track down an issue with prototype which i'm still looking into.
Basically my code did something like this
create a div element, apply some style (including a width)
div element.morph({width: n%}); where n is the new value i wanted.
Had an ajax request getting the new width from the server and then
calling this routine every 200ms
Let this run for a while and found it was gaining memory.
Then tried all of the above, except instead of div element.morph, i
used setStyle, no memory loss.
This gave me the evidence i needed to blame the morph function. Once i
had that i started looking into what the function was doing, breaking
down the various aspects of the function. Somewhat trial and error, i
looked at what the setup function was doing and quickly realised what
each bit was doing, i knew i was modifying the width of values so i
looked at how that was working. I develop in the Aptana IDE and turned
on warnings mode, which uses JSLint to find possible issues. The first
thing it mentioned was that var was missing a preceding { for the
function, then it mentioned that value and unit had already been
defined.
I think by chance i caught it, when i changed the code and ran it, the
memory leak was gone.
I wrote a small test case which is here: http://pastebin.mozilla.org/3901
to replicate the problem in the future, i think its a bug with
firefox, but really dont have time to persue it, i cant imagine EVER
writing a function that compressed ;)
One bit of advice i could offer, is try and isolate which bits are
causing the problem, so if you know you've got a leak, comment out all
of your code and run the page again, if the leak is still happening
then look further afield, if its not, then introduce a small portion
of the code back in, and retry until you eventually isolate which bits
of the code are causing it, then isolate these and run them on their
own and just keep working like that until you can track it down. Thats
all i do :)
On Feb 14, 6:49 pm, Colin Mollenhour <[EMAIL PROTECTED]>
wrote:
Good work, I am *very* curious as to how you were able to track this
down as a memory leak? My Firefox will creep up to >250Mb memory rather
quickly and although I am pretty sure I don't redeclare variables as is
the problem in this case, I'd like to learn more about tracking down
these obscure memory leaks nonetheless.
Thanks,
Colin
Malard wrote:
Hi all,
I have noticed that the new morph functions of script.aculo.us are
causing a severe memory leak in firefox if used for a sustained
period, f.ex my application of it was using it to dynamically change
the length of a div and the colour of that div, for a web based
overview of load balancing on several computers.
What was happening that after about a day, firefox would consume
around 2gb of memory. After some careful investigation it seems that
the morph effects were leaking the memory.
In the 'setup' function in Effects.Morph starting line 981
} else if(Element.CSS_LENGTH.test(value))
var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/),
value = parseFloat(components[1]), unit = (components.length
== 3) ? components[2] : null;
This function already is already declaring value and unit on line 972,
it seems there is either a bug in the _javascript_ engine in gecko or
the garbage collection as the values being reassigned on the
concatonated var statement on line 982 are the only cause of the
memory leak.
Modifying these lines to the following:
} else if(Element.CSS_LENGTH.test(value)) {
var components = value.match(/^([\+\-]?[0-9\.]+)(.*)$/);
value = parseFloat(components[1]);
unit = (components.length == 3) ? components[2] : null;
}
Resolves the issue entirely. Can other people verify and possibly
direct me to how i can add this to the library proper.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
|
