Tuesday, November 29, 2005

Two New Tapestry Committers: Jesse Kuhnert and Kent Tong

The Tapestry project has just added two new committers!

  • Jesse Kuhnert - Very active with the Tacos component library, which is the hub for Ajax components for Tapestry. He's got an inside line on what it'll take to make Tapestry the best framework for Ajax development.
  • Kent Tong - Active mentor on the user and developer mailing lists, Kent has been keeping me and the other Tapestry committers honest for quite a while now ... and he's written a great book on Tapestry 4.

Great things are afoot for Tapestry ... fresh blood, a final 4.0 release very, very soon now, and an increasing number of high profile sites in the pipeline (and no, I can't say more).

Thursday, November 24, 2005

Tapestry @ JavaForge

I'm just about done setting up Tapestry @ JavaForge, an auxillariy site for Tapestry components and extensions. I've been experimenting with Maven 2, so far with some decent success. I especially like the Wiki-ish "almost plain text" format for documentation. Maven 2 still has a number of teething issues, and I haven't even touched the critical multi-project support yet, but I'm cautiously optimistic.

No downloads just yet, but the source code is easily accessible via Subversion and builds using Maven, which is close enough.

Can you tell I'd really rather not be balancing my checkbook right now? Merry Turkey-Day!

No Tapestry at ApacheCon 2005

Hope I'm not disappointing too many people, but I will not be able to do the Tapestry Tutorials at ApacheCon on Dec 10th, as previously stated. They didn't get enough tutorial sign ups by their Nov. 12th deadline (ApacheCon does terrible marketing), and since I really hadn't wanted to do a tutorial in the first place, I offered to cancel rather than try and come up with a last-minute way to boost attendance.

I was somewhat looking forward to this, since I haven't done any speaking engagements in too long. But with Tapestry 4.0 in the final stages, plus the fact that, as I type this, I'm supposed to be stuffing books into boxes for my move to Portland, Oregon next week ... well, let's just say that skipping ApacheCon goes a small way towards easing my monumental stress level.

Wednesday, November 23, 2005

Woops! Killed JavaForge.com

I think I may have killed JavaForge. No, really. It seems to have blown up and crashed hard as I was uploading the tapestry-prop site tarball into their documenent management system.

I really want to like JavaForge because it is free, and because it allows Subversion hosting ... but any instability (it's been down for about 30 minutes now) is troubling.

Tuesday, November 22, 2005

And Apache's JIRA is down again ...

... and I was going to fix all those outstanding Tapestry bugs tonight. :-) But I can't. Sigh.

Monday, November 21, 2005

Documentation for Script Templates

We're in the final stages of Tapestry 4.0, trying to fix the most glaring documentation ommissions, and tidy up the bug list.

I've finally written documentation for the script template specification DTD, which is a very important file with the growing emphasis on JavaScript with web applications.

Tapestry has had, for a few years, some very advanced code for generating dynamic JavaScript to complement the dynamic HTML. It's centered in these script templates that take care of organizing the JavaScript into two large blocks (one at the top of the page, the other at the bottom) ... which is better than having it scattered about. As importantly, the JavaScript generation understands the need for uniqueness, to prevent name collisions in client-side variables and functions. This is the infrastructure that lets clever folks, like the ones at Tacos, create Ajaxian components that just work without any special attention by the developer ... regardless of whether there's just one such component, or dozens, on a page. Tapestry has the infrastructure to support this, with out requiring any special configuration of servlets or anything else.

Friday, November 11, 2005

Improving Tapestry performance

I just spent the week with a high profile client that is interested in potentially using Tapestry for a very large scale site ... millions of hits per hour. Their in-house framework is quite capable of operating at this scale, through a combination of draconian restrictions on database access and server-side state, and a total avoidance of any kind of reflective object access. These are people who literally cannot give an inch on performance.

One of the ideas that bounced around was something promised for some future release of OGNL: bytecode enhancement. That is, in some cases, OGNL 3 is expected to identify places where it can create a class on the fly to expedite access to a property, rather than always relying on reflective access as it does today.

Alas, that hasn't happened yet, and Tapestry is still using OGNL 2.6.7.

But, I thought, what if we created a new binding prefix to use instead of OGNL, for this purpose. Because of HiveMind, this approach can be packaged seperately from the framework proper, and plug right in.

... and it works. I built a little peformance test harness and tried to figure out how many nanoseconds it takes to perform an operation; an operation involves a read and then an update. Here's one of the operations from the harness:

        Op op = new Op()
        {
            public void run(PropertyAccessor accessor)
            {
                Long value = (Long) accessor.readProperty();

                long primitive = value.longValue();

                accessor.writeProperty(new Long(primitive + 1));
            }
        };

The PropertyAccessor object is either created from bytecode, or implemented using OGNL (so that we can make the comparisons).

I did a number of test runs, with a number of operations:

              10000 iterations |  Direct ns |    OGNL ns
------------------------------ | ---------- | ----------
                 name - warmup |    4288.00 |  847364.00
                          name |    1777.00 |   18426.00
                  int - warmup |    2891.00 |   81127.00
                           int |     838.00 |    7497.00
                 long - warmup |    2969.00 |   28207.00
                          long |     617.00 |    7256.00

             100000 iterations |  Direct ns |    OGNL ns
------------------------------ | ---------- | ----------
                 name - warmup |    4282.00 |  819634.00
                          name |     972.00 |    7527.00
                  int - warmup |    2947.00 |   74425.00
                           int |     242.00 |    5955.00
                 long - warmup |    2910.00 |   27492.00
                          long |     209.00 |    6046.00

             500000 iterations |  Direct ns |    OGNL ns
------------------------------ | ---------- | ----------
                 name - warmup |    4182.00 |  852125.00
                          name |     857.00 |    6756.00
                  int - warmup |    2958.00 |   81820.00
                           int |     170.00 |    5724.00
                 long - warmup |    2793.00 |   34990.00
                          long |     215.00 |    5785.00

          2,000,000 iterations |  Direct ns |    OGNL ns
------------------------------ | ---------- | ----------
                 name - warmup |    4251.00 |  843185.00
                          name |     823.00 |    6553.00
                  int - warmup |    2927.00 |   48788.00
                           int |     144.00 |    5799.00
                 long - warmup |    2961.00 |   34945.00
                          long |     180.00 |    6173.00

The results show that the direct access is around 10x faster than reflective access, which is in line with the general documentation about reflection in JDK 1.5. Still, I'm troubled that the cost per operation seems to continue going down as the number of operations increases. This could be the effect of hotspot (though the elapsed time seems short for hotspot to get very involved) ... or it could represent a problem in my performance test fixture.

To use this, you just use the prefix "prop:" instead of "ognl:". And, of course, it only works for simple properties, not property paths or the full kind of expressions used in OGNL.

I'm hosting the code on JavaForge and will make some kind of release available soon. Perhaps it will migrate into the framework proper at some point.

Friday, November 04, 2005

Further Down The Trail

Chris Nelson has published his second article on Trails: Further Down the Trail.

Seems like a lot of people are getting excited about Trails, and rightly so. I can see a large number of projects getting built this way. It's a great idea, it's developer-focused, it gets you great results fast. I've also seen Chris mention integrating Ajax components from Tacos. What's easier than using Tacos components for Ajax behavior ... using Trails and getting the Ajax stuff for free!

By the way, one of the most remarkable aspects of Trails is that Chris has been building Trails as a way to learn Tapestry. Either Chris is really some kind of comic-book alien machine super-intelligence (unlikely, I've met him in person), or Tapestry isn't quite as hard to learn as some people seem to think. Perhaps Chris had less Struts and JSP clutter to unlearn.