commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [betwixt] Time and memory performance
Date Sun, 07 Aug 2005 13:26:57 GMT
On Sat, 2005-08-06 at 10:14 -0700, Kirill Grouchnikov wrote:
> Robert,
> 
> You are more then welcome to provide the correct use of
> Betwixt for optimal time and memory footprint. There are
> couple of things that you should be aware of:
> 
> 1. The default options should be the best ones. If i need
> to tweak the settings, most of the chances are that i'll
> miss it (as i did). 

all dynamic binders by their nature require tuning.

though your benchmarks are useful for generative binders, they not all
that informative for the dynamic binders. all dynamic binders are slow
(since they use reflection). what's crucial (for users) is whether they
can be tuned. two sets of benchmarks (vanilla and tuned) would be more
interesting and useful for the dynamic binders. 

> 2. If it takes a first-time user that looks at the examples
> more than 4-5 hours to make the library even work, chances
> are that this user will no longer be a user.

i would expect most users either to follow the example as documented or
know that private static inner classes are inaccessible. 

i would also not expect most users to use ByteArrayOutputStream  unless
they knew enough about it to realise the need to flush the stream.

> 3. BeanReader is not reusable, producing empty results
> after the first unmarshaling. 

SAX is by it's nature single threaded. so there really isn't too much to
gain by pooling readers. 

> 4. It says in the documentation that XMLBeanInfoRegistry is
> the default choice, so how do i share them and why it's not
> on the first page of the documentation?

the slowest part of the process is introspection. though bean readers
are no reusable, registries are reusable and can be shared. 

> The team is (once again) more than welcome to see the
> source code and to send me the corrections, which will be
> incorporated, assessed and published.

does this include correcting the mistakes on the ease-of-use page?

not only is the betwixt entry inaccurate but i've noticed mistakes in
several others as well. IMO it's sloppy methodology not to post your
comments to the project in question first so that you have a chance to
correct your mistakes before they are made public. by labelling a
document as subjective does not excuse inaccuracies. 

> The personal biases are outlined for all to see in the
> project FAQ, and everyone can draw his / her own
> conclusions on the weapon of choice.

IMO your project would be far more effective if it didn't suffer so much
from being obviously just one man's opinions. setting yourself up as a
expert without taking great care to ensure that you understand the
subject and that your criticisms are accurate is to invite attacks on
your personal integrity. 

the project would also be more useful if you tried to educate users
about how to choose the most suitable binder for their problem. 

you show a consistent bias against start-from-java binders in favour of
start-from-schema binders. for example, you consistently list 'Requires
writing your own classes' as a negative point but this is the whole
point of start-from-java binders! if you don't like start-from-java
binders, it would be more honest to write this at the top of the page.

this bias extends to the benchmarks as well. i would be interested to
see additional benchmarks organised to hit the start-from-java hot spot
rather than the start-from-schema one. 

i also find your treatment of JAXB binders confusing. not only do you
confuse the specification with the reference implementation but
shouldn't all implementations be equally easy to use?

your ratings of the generative binders also do not seem to accord with
experience. JAXB is known to be a difficult specification to work with.
i think that most people would be very surprise to see the JAXB
implementations rated so highly in terms of ease of use. i note that you
acknowledge this in the FAQ. 

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message