launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

On Thu, Sep 20, 2012 at 5:20 AM, Gavin Panella
<gavin.panella@xxxxxxxxxxxxx> wrote:
> 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.

I understand. I think Rick had a similar WTF lobe moment from it.  It
makes sense to me, though.  DOM manipulation is indeed the slowest
thing in js code, but scope chain, execution context, and all the
other stuff related to member resolution that js engines do is pretty
slow, too.  There is indeed prototype lookups.  I just haven't been
that picky about it because I figured we would get hit by slow DOM
work before this, just like you say.  Paul has long thought we were
crazy to not be picky about it and assumed it would get us one day.

And no, we aren't seeing this on post-Lucid machines.  Sorry if Rick
or I gave that impression.  It's limited to ec2 test.  Once we're all
post-Lucid with builders this will be less of a problem, so I don't
think we should overreact.  That's why I'm suggesting we not get too
crazy with shortening the namespace.  Most YUI projects tend to stick
with the module name, and stay one or two levels deep from the Y
namespace.  This seems reasonable to me and we could drop the "lp"
since it's a given that any of our code is lp code.

I think the general guideline should be: "Anything more than 3 levels
deep should raise a red flag in review."

As for profiling, I have no idea how to profile in html5-browser.
Maybe Curtis has ideas?  If you just need some peace of mind that
member resolution is really a cause for concern, we could do a test in
FF and Chrome using their profiler tools.  Also, "High Performance
JavaScript" has a great chapter on all this, if you haven't read that
book yet.

Cheers,
deryck

-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/