[whatwg] Proposal for separating script downloads and execution

>> I dunno if
>> I'd call that a "memory leak" as much as I'd call it a "higher memory
>> utilization", or maybe "potential memory waste".
>
> Most users will call continuously increasing memory (which is what you'd 
> get if a page creates script elements, sets src, and then doesn't insert 
> them, perhaps by accident) a memory leak.

In my experience, the term memory-leak (both in the IE sense and in the 
C-programming sense) is not about continuously increasing, even run-away 
memory usage, so much as it is that memory gets into a state where it cannot 
be re-claimed. I don't see you saying that this memory usage would be of 
that type, so I still don't think it's right to call it a "leak" as much as 
a "non-release (yet)". But that's probably just a side semantics issue. You 
say "tomato", I say "tomato".


>> or is it a lot more? Compared to the 100-300
>> MB of memory that a Firefox instance takes up on my computer, what
>> percentage of that would be (or would be increased) if Firefox were also
>> holding onto even a large amount (~200k) of not-yet-used JavaScript code
>> in memory?
>
> My worries are cases where a page inadvertently makes you hold on to tens 
> or hundreds of megabytes of js, not about the 200k case.

Do you have any example where hundreds of megabytes of JavaScript is being 
loaded onto pages? Even "tens of megabytes" seems quite extraordinary. I 
believe I recall reading somewhere that the average amount of JavaScript on 
the Alexa 200,000 is like 375k. I think the most I've ever personally seen 
is around 2-5 MB. Even if we factor in long-running pages (like Gmail, for 
instance), I can't fathom that during the course of the page lifetime, all 5 
MB of JavaScript code is being re-downloaded fresh, every few minutes or 
hours, in which case a run-away scenario of "hundreds of megabytes" might 
occur. Even then, it would only occur if that site were re-downloading their 
entire code again, over and over, but never using it. That would be bizarre, 
indeed.

And not only would it be bizarre if that were happening by design, but it'd 
be bizarre if it was just a random flaw in their software, which for all 
other browsers didn't bite them but somehow they avoided that flaw in IE, 
where it should be killing them.


> I think you understimate how often scripts just have bugs in them.  I'm 
> not saying someone would create a few million nodes and then not insert 
> them in the DOM because they're _trying_ to do something dumb.  But that 
> sort of thing scripts do all the time.
>
> You're assuming scripts mean to do everything they do.  That's not a good 
> assumption, unfortunately.

Here's what I'm assuming: more than not, this feature will be used 
appropriately. That's not an exclusive thing that ignores mistakes or bugs. 
But the nature of what we're suggesting is not quite as likely to be 
accidentally happening as many other potential features we might discuss for 
HTML.

I haven't seen any examples of existing sites where the "millions of script 
nodes" phenomena is happening right now, which would be potential landmines 
for this newly suggested "preloading" functionality. The fear of it being 
theoretically possible seems much more intense than any evidence or logical 
reasoning for it being probable.

I also am on record as saying that I think it's a bad idea to avoid a useful 
(to some) feature for fears that others (probably the minority) will abuse 
or misuse it. That's why we have technical/performance evangelism. That's 
one way the open-source community is so vibrant. In fact, that's why Firefox 
was able to contact several different websites which broke as a result of 
the whole "async=false" thing, and re-educate them on how to properly 
proceed. To my knowledge, that process worked ok, and I think it's a decent 
model for going forward.

Unless someone can show that the majority of sites (or even just something 
greater than a tiny fraction) are going to choke. And if that can be shown, 
I welcome it. But I'd also be extremely curious as to how those same sites 
are (probably) surviving fine in IE, which has been doing this preloading 
for a decade or more. It's I guess possible, but I'd highly doubt, that 
there are sites which, only for IE, are intentionally avoiding preloading by 
not creating script nodes, whereas they happily queue up "millions of nodes" 
in all the other browsers.



--Kyle

Received on Thursday, 17 February 2011 09:23:12 UTC