Skip to Content.
Sympa Menu

xom-interest - RE: [XOM-interest] static Builder.create methods instead of const ructors?

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "New, Cecil (GEAE)" <cecil.new AT ae.ge.com>
  • To: "'Wolfgang Hoschek'" <whoschek AT lbl.gov>, xom-interest AT lists.ibiblio.org
  • Cc:
  • Subject: RE: [XOM-interest] static Builder.create methods instead of const ructors?
  • Date: Fri, 13 Aug 2004 07:35:46 -0400

I can't judge the overhead required for a builder. But by analogy, app
servers do pool database connections - for which to open incurs high
overhead. And they make a huge difference in performance. If builders also
incur such overhead and many are needed and used concurrently, then pooling
would make sense for them as well.

Just my $.02

-----Original Message-----
From: Wolfgang Hoschek [mailto:whoschek AT lbl.gov]
Sent: Thursday, August 12, 2004 9:42 PM
To: xom-interest AT lists.ibiblio.org
Subject: Re: [XOM-interest] static Builder.create methods instead of
constructors?


On Aug 12, 2004, at 5:41 PM, Elliotte Rusty Harold wrote:

> I just don't see the problem here. The only reason you would ever care
> about this is if for some strange reason you're creating thousands and
> thousands of Builder objects, and that's not a plausible use case
> because builders are reusable. If you want to parse documents in
> parallel in separate threads, give every thread gets its own builder.
> Problem solved.
>
> You seem to be proposing a very complex solution to a very easily
> solved problem. Is there something more complicated here I'm not
> seeing?
>

It's obvious for simple demo usage or for hard-wired designs where one
can make assumptions about usage, and non-trivial if you have a
framework where it's classes are decoupled and should not care about in
which thread and in which environment they are being used. For example,
think webservice in container with concurrent requests, with XML
parsing usage decentralized in all sorts of corners of the framework.
You are not in control when and where and how new threads are created,
you just live in arbitrary contexts...

Anyway, the bottom line is that Builder reuse is often a lot more
complicated than simply constructing a new Builder() in each
method/class where one is required, and so they're not reused in
practise, and so the performance penalty is indeed large. What do other
folks think? What's their current practise? A new Builder everytime you
need one? Curious...

_______________________________________________
XOM-interest mailing list
XOM-interest AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/xom-interest




Archive powered by MHonArc 2.6.24.

Top of Page