On 19 September 2012 14:25, Deryck Hodge <deryck.ho...@canonical.com> wrote: > It's not just the assignment or lookup alone; there's also the > performance hit for creating that namespace. Also, that assignment > hit has to be paid over and over in each test. Every JavaScript book > will note that nested properties are slow in every browser. We've > just been lazy about this. Now we have definitive proof that it costs > us something -- i.e. Rick had a test that failed due to a timeout > error, due to these long namespaces. So it makes sense to fix it now, > or at least not make it worse going forward.
I guess it's an interpreter problem, though Curtis says there's massive improvements in WebKit since Lucid. I assume these problems are being observed on post-Lucid machines? It seems unbelievable that four/five lookups should be so expensive, especially compared to, say, manipulating the DOM, but I guess JavaScript has the potential for prototype lookups too along the way. Do you know of any decent profilers that could incontrovertibly confirm the root cause? I know you guys have shown that reducing namespace lookups helps, but I'm still amazed that this is a problem, and I don't know how else to silence my brain's WTF lobe. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
