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: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: "New, Cecil (GEAE)" <cecil.new AT ae.ge.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] static Builder.create methods instead of const ructors?
  • Date: Fri, 13 Aug 2004 11:56:29 -0700

Precisely :-)
A general purpose pool holding N builders isn't needed in most cases though, just a class that maintains (and can return) one builder per thread.

On Aug 13, 2004, at 4:35 AM, New, Cecil (GEAE) wrote:

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