2010/1/20 Bjorn Tillenius <[email protected]>: > 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 <[email protected]> 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). _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
