That's Not a Memory Leak, It's Bloat(engineyard.com)
engineyard.com
That's Not a Memory Leak, It's Bloat
http://www.engineyard.com/blog/2009/thats-not-a-memory-leak-its-bloat/
Think you know the source of the issues in your Rails app? Check again ...
2 comments
The link caused my anti-virus (McAfee) to pop a warning. A quick Google search says:
"McAfee Avert Labs has found a false detection with JS/Exploit-Packed.c.gen and will be releasing the 5729 DAT Files to correct this issue. The false detection is being seen on websites containing certain types of javascript obfuscation"
How do you tell if it's a false positive? I wonder why javascript obfuscation is needed? Any smart people out there know the answer (and interested enough to share it?)
"McAfee Avert Labs has found a false detection with JS/Exploit-Packed.c.gen and will be releasing the 5729 DAT Files to correct this issue. The false detection is being seen on websites containing certain types of javascript obfuscation"
How do you tell if it's a false positive? I wonder why javascript obfuscation is needed? Any smart people out there know the answer (and interested enough to share it?)
Many sites use packed/compressed/minified javascript. That page in particular uses a number of jQuery related libraries that probably come pre-minified. This cuts down on their size, making things quicker. It also happens to obfuscate the scripts.
There are some people who obfuscate for the sake of it, but it's generally not very effective. We have various ad providers try and get us to host obfuscated iframe buster scripts (so they can expand ads outside of iframes). Those types of scripts are so prone to cross site scripting attacks that we've started informally auditing them before we put them out. When they won't give us the nicely formatted and commented source (it's dumb), we just run them through various javascript prettifiers to have a look anyway.
There are some people who obfuscate for the sake of it, but it's generally not very effective. We have various ad providers try and get us to host obfuscated iframe buster scripts (so they can expand ads outside of iframes). Those types of scripts are so prone to cross site scripting attacks that we've started informally auditing them before we put them out. When they won't give us the nicely formatted and commented source (it's dumb), we just run them through various javascript prettifiers to have a look anyway.
The real problem isn't that MRI gobbles up memory when loading libraries, but that it is constitutionally incapable of sharing that memory between processes.
If it didn't have such a ridiculous mark-and-sweep GC that insists on periodically writing to every damn page, libraries loaded before calling fork() would be optimally shared by the descendants.
If it didn't have such a ridiculous mark-and-sweep GC that insists on periodically writing to every damn page, libraries loaded before calling fork() would be optimally shared by the descendants.