Barracuda Performance Questions

Hi Xue-Feng,

I've kind of come late to the discussion, so I'll just dive in and then let
you ask followup questions as need be.

First a couple of generic comments on performance.

a) Barracuda's event model is highly optimized for performance, and should
be thoroughly scalable (we tested it extensively when we first built it to
ensure that)

b) Barracuda's component model should be _fundamentally_ scalable, although
some of the things we currently do (ie. standard/default implications) still
have plenty of room for optimizations.

In general, here are some areas in Barracuda that may impact
performance/scalability.

1. the Barracuda component bases everything on the DOM interfaces. As Jake
pointed out, if you are fundamentally convinced that that is bad, well,
there's not much we can do for you. Of course you could still use parts of
Barracuda (events/forms) that are NOT related to the DOM, but the component
model won't buy you much if you don't want to go te DOM route.

2. that said, the Barracuda component model is NOT tied to a specific
implementation of the DOM. SO...you could create your own DOM loader if you
wanted to that had all the "static portions" of the DOM collapsed as a
single node, and you could use Barracuda to manipulate just the dynamic
portions of the DOM

3. LazyDOM actually does this very thing, plus it gives you the added
advantage of being able to expand those static nodes if you end up needing
to. My understanding of LazyDOM is that unexpanded DOM nodes are rendered in
one fell swoop - they are not expanded in order to be rendered.

4. The reason Barracuda doesn't _typically_ benefit from the LazyDOM is
twofold:

a) the default implementation of BTemplateViewHandler binds a single
BTemplate component to the top of the page and simply parses everything
underneath it. The advantage of this is that the developer doesn't have to
know any specific tag names in the template (ie. separation of presentation
vs. application logic). The downside is that this convenience means that
everything in the page will get parsed and thuse expanded and thus LazyDOM
is moot. The key here, however, is that this is NOT an architecural
necessity of the Barracuda framework as a whole - its an implementation
detail of a default case, which works very well for the majority of use
cases. But you are totally free to implement a different strategy - the
framework was designed to allow you to do this.

b) one of the other areas of slowness is the ElementFactory infterface -
when you create a View on a node, it creates an ElementFactory for
everything underneath that node, which means making copies of all the
elements in the source template. SO...if you are using a BTemplate and you
bind it to the top of the page, the whole thing is going to get cloned so
that you have copies of everything hanging out in ElementFactory. This is an
obvious performance penalty - the DOM will get expanded completely even
before the components start rendering. Its my previously stated objective to
remove this interface entirely, and this should result in significant
improvements in performance. But right now, it _is_ still an issue
(tecnically). Interstingly, however, if you search the archives you will see
that practically speaking there are very few people who are having problems
with Barracuda performance. This is probably a result of the fact that the
community is still relatively small (compared to something like Struts); but
pragmatically, Barracuda performance hasn't been a problem yet. I will
concede that it could be in certain situations (but that probably holds true
for just about any framework). At least we're open and honest about it ;-)

5. In the area of DOM size, my experience has found that browsers choke on
really large DOMs before the server side processing does. So one of the very
real implications of a DOM based approach (or rather an HTML based
approach - the browsers convert the HTML to DOM internally), is that if you
have hundreds of complex pages, HTML/DOM is going to be problematic on the
client side - not because of the server technology, but because the browsers
simply can't handle that big of a page. :-(

6. On the server side, one of the things we have done to make it possible to
_render_ really big DOMs is to create a BlockIterator, which basically
renders the DOM out on the fly, creating/rendering BTemplates for individual
blocks of markup, rather than trying to process the whole thing in memory.
This allows for immediate streaming of content back to the browser. The
_disadvantage_ of this is that Barracuda components cannot render into other
portions of the DOM (to attach script components, etc). In other words, they
are limited to the context of the block they are associated with in terms of
what they can manipulate at render time. For reports, this is probably not a
problem; for forms (ie. with submit buttons, etc) it wouldn't work.

Ok, so I've probably said enough. Feel free to comment as you see fit.

> Yes, of course. I am an expert on parsers and
> compilers. I wrote some parsers on XML, EDI and Cobol.
> I also a Senior Technical Architect on J2EE, and a
> professor. I am very interested in to making some good
> framework and its related (design/development/testing)
> tools.

It'd be great to have you pitch in and contribute - I think you could
benefit from Barracuda, and it sounds like Barracuda could benefit from you
as well. I think as you spend time here you will see that we are _very_
committed to performance and extensibility. We don't want to lock anybody in
to any one particular way of doing things, because we realize that everybody
has different needs. But we do want to make it easy for folks do do things
with prebuilt pieces for commonly encountered situations. So you kind of
have to distinguish between the architecture and the implementation as you
evaluate Barracuda.

If you have any further question and comments, please don't hesitate to ask.

Cheers!
Christian
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Xue-Feng Yang
> Sent: Monday, March 17, 2003 12:31 AM
> To: [email protected]
> Subject: Re: [Barracuda] Why does Barracuda choose the way to parse the
> whole page (*ML) to a doc?
>
>
>  --- Jacob Kjome <[email protected]> wrote: >
> > Hi Xue-Feng,
> >
> > See comments below...
> >
> >
> > I should be a bit more clear on this.  The Barracuda
> > *component* model
> > expects a w3c compliant dom.  The event model and
> > the forms model are
> > utterly disconnected from the component model (and
> > from each
> > other).  Therefore, if you like the event framework,
> > then use that and use
> > whatever presentation strategy you like.  If you use
> > the Barracuda
> > component model, at least as it stands currently,
> > then you are going to
> > deal with w3c dom.  This doesn't prevent you from
> > building your own
> > component model.  Use whatever strategy you like.
> > That is the beauty of
> > Barracuda.  It doesn't tie you into any one
> > presentation strategy.  There
> > are people that use JSP with Barracuda, although I
> > can't fathom why?
> >
>
> Yeah, I may make my own. I am still evaluating some
> available frameworks now.
>
> > The basic point is, if you believe that the w3c dom
> > is simply a dog in
> > performance, then use something else.
> >
> >
> > Well, in a page that contains one dynamic data
> > member, utilizing XMLC's
> > LazyDOM won't automatically open all 1,000,000 nodes
> > just to modify that
> > one node.
>
> I think you misunderstand here. It is true that you
> can modify LazyDOM without openning other nodes, but
> when you get the updated page from LazyDOM, you must
> parse all of the nodes. That is painful.
>
> >This is, of course, not the default
> > behavior of most w3c
> > compliant dom models.  I think Xerces2 has one as
> > well, but I'm unfamiliar
> > with it.  The DOM does have its caveats, but there
> > are many people who have
> > used it successfully with reasonable performance.
> > The big draw of the DOM
> > (and XMLC specifically) is allowing for the clean
> > separation of *ML
> > developers from the Java developers (and the
> > fine-grained control the
> > developer has over the DOM document).  I assume your
> > "sqeezing" strategy
> > doesn't give that up, does it?  If it does, then we
> > are talking apples and
> > oranges.  Surely there presentation strategies that
> > provide for better
> > runtime performance than the dom, but most give up
> > the clean separation
> > that the dom provides in order to achieve the better
> > performance.  That's a
> > deal breaker for me.
> >
> > BTW, do you have working software that implements
> > your "squeezing"
> > idea?
>
> Yes, of course. I am an expert on parsers and
> compilers. I wrote some parsers on XML, EDI and Cobol.
> I also a Senior Technical Architect on J2EE, and a
> professor. I am very interested in to making some good
> framework and its related (design/development/testing)
> tools.
>
> >Like I said above, you can use any
> > presentation strategy you
> > want.  Barracuda's event model is more than
> > compelling on its own.  Use it,
> > discard the rest, and implement a component model
> > using your squeezing
> > strategy.
>
> It is relatively easy to have some beautiful
> frameworks. However, it is very difficult to have both
> beautiful and good performance. Since much deep
> algorithms will be involved in later case.
> Unfortunately, most developers don't understand these.
> I saw a very good J2EE framework for the financial
> industry. The performance of one implementation I saw
> was not very good.
>
> >I'm sure people here would be interested
> > in that.  Contributions
> > are always welcome.
> >
>
> It might be a good project for my students.
>
> >
> > Jake
> >
> > >
> >
>
> ______________________________________________________________________
> Post your free ad now! http://personals.yahoo.ca
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda