launchpad-dev team mailing list archive

[Tom Berger <tom.berger@xxxxxxxxxxxxx>]

2010/1/20 Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>:
> On Wed, Jan 20, 2010 at 06:21:37PM +1300, Bjorn Tillenius wrote:
>> On Tue, Jan 19, 2010 at 10:44:16AM -0700, Paul Hummer wrote:
>> > On Mon, 18 Jan 2010 22:03:16 +1300
>> > Tim Penhey <tim.penhey@xxxxxxxxxxxxx> wrote:
>> >
>> > > I have a branch that just modifies some javascript.
>> > >
>> > > lp:~thumper/launchpad/js-play
>> > >
>> > > I'm trying to land this on devel, but it fails 42 windmill tests running
>> > > through ec2 (I'm pretty sure this is all of them).
>> > >
>> > > However the tests pass locally.
>> >
>> > I'm willing to bet they are the same ones that are failing on me in ec2.  It
>> > fails on all sorts of commands, including client.asserts.assertProperty and
>> > client.waits.forElement. They also fail locally, unless I run the tests with
>> > bin/test -D, and then they don't fail.  That's the real pisser.  It indicates
>> > to me that there's a timing issue on tests, and my change just changed the
>> > timing issue. I'm tempted to just land this branch. None of the tests are tests
>> > that touch code that I've touched and I'm also stumped.
>>
>> I took a look at this today. I will continue tomorrow, unless someone
>> else takes figures out what's going on here while I'm asleep. I haven't
>> found the real issue, but I did find some interesting results. If I run
>> the test in latest devel (r10197), everything is fine. If I then apply
>> the patch of the changes in Tim's branch, the test runner suddenly takes
>> 100% CPU on my machine while running the Windmill tests. This is odd,
>> since the patch is JS only. I've done a profiling run of the tests with
>> the patch applied. I haven't had time to analyze the results, but if
>> someone is up for it, you can find the .prof file here:
>>
>>     https://devpad.canonical.com/~bjorn/r10197-with-js-play-patch.prof
>>
>> The patch that I applied is here:
>>
>>     https://devpad.canonical.com/~bjorn/js-play.patch
>
> So, I still haven't figured out what's wrong yet; I'm still
> investigating. I've noticed one thing, though. Without Tim's patch,
> the generated launchpad.js is 511 870 bytes. Slightly less then 500 kb.
> With Tim's patch, launchpad.js is now 512625. Slightly more than 500 kb.
> In fact, I ran some test just now to confirm my theory. I took a plain
> launchpad.js and added whitespace to it. When it's 512 000 bytes,
> everything is thing. If it's 512 001 bytes, the test runner uses 100%
> CPU. So something is becoming very inefficient when dealing with files
> larger than 512 000 (500*1024) bytes. Does this magic number ring any
> bells?
>
> BTW, if you want to get some JS patch landed, a workaround could be to
> find JS code that we don't use, and exclude it when generating
> launchpad.js to make it smaller.

Brian and I killed some JS code today, in a branch I'm about to land.
Maybe that will improve things a bit (but it's much less than Tim's
additions).

If we're stuck, maybe we should stop concatenating JS files until we
find a better solution (and if 500kb is the limit then we may have to
go with several concatenated JS files, each weighing less than that
limit).