launchpad-dev team mailing list archive

[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.


-- 
Björn Tillenius | https://launchpad.net/~bjornt