launchpad-dev team mailing list archive

[Gavin Panella <gavin.panella@xxxxxxxxxxxxx>]

On 19 September 2012 14:25, Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx> 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.