--- Simon Kitching [EMAIL PROTECTED] wrote:
I stopped using belief as a measurement of code a long time
ago. Usually only works when I wrote all the code. :-)
I'll cook up an experiment and see what I can come up with
in the way of timing information.
That would be excellent. I look
--- Simon Kitching [EMAIL PROTECTED] wrote:
On Thu, 2005-02-03 at 07:52 -0800, Reid Pinchback wrote:
Even for Sax the performance difference between (a) and (b) is roughly
a factor of 2 across all parsers when processing small (typical
message-sized)
docs that don't use NS.
I
--- Simon Kitching [EMAIL PROTECTED] wrote:
On Wed, 2005-02-02 at 20:45 -0800, Reid Pinchback wrote:
Of course if someone can demonstrate that non-namespace-aware parsers
*are* still useful then I'll change my mind.
Just to clarify, since I was being sloppy before (I gotta
stop typing
One section of the release notes says:
The Digester now *always* uses a namespace-aware xml parser.
I was wondering why this is. There are a lot of XML parsers
out there, and some of them have done things like trade
namespace awareness for performance. If somebody has a
application where
--- Oliver Zeigermann [EMAIL PROTECTED] wrote:
On Wed, 02 Feb 2005 18:28:04 +1300, Simon Kitching [EMAIL PROTECTED] wrote:
My major concern is that if we are going to warn people not to implement
the Action interface,
then what really is the point of providing it in the first place? As I
--- Simon Kitching [EMAIL PROTECTED] wrote:
Supporting namespaces in an xml parser seems very simple to me. I think
it much more likely that only antique and unmaintained parsers fail to
support namespaces. And people who are determined to use antique and
unmaintained parsers can just stick
--- Simon Kitching [EMAIL PROTECTED] wrote:
Does this mean you prefer Action to Rule? I certainly expect to hear
from people who want to keep the current names...
I'm not wedded to Rule but I do have a concern about Action.
I suspect it could make Struts code rather confusing.
--- Simon Kitching [EMAIL PROTECTED] wrote:
Ok, we'll see what the general consensus is. I happen to personally like
prefixes rather than suffixes, but will go with the majority opinion.
I vote for prefixes.
That sounds reasonable. However I do dislike having mutual dependencies
between
Sure thing. Just to make it easier to envision, let's get
packages out of the equation. Just think about cyclic
dependencies between two classes in the same package.
That is enough to show the problem; packages just add complexity
because the dependencies can be much harder to detect visually
I won't repeat my previous comments re: JUnitPerf,
but they apply here too. Just looked at the bench
case stuff, looks decent, better for fast tests of
small code fragments. Whether it is appropriate
or not depends on what you are trying to achieve.
If you want to be able to record measurements
--- Simon Kitching [EMAIL PROTECTED] wrote:
You should be warned, though, that the logging area
is particularly tricky.
Yup, I figured that could be the case. Before
I even proposed this I'd already decided that I'd
just float each change as a proposal, and just grin
and bear it if there
FYI, I've verified that yes, the Digester
substitution facilities in 1.6 can be used
to do the same kind of variable substitution
that Ant has. Just wanted to send in a note
so nobody wastes time tackling the same
problem. Once Simon has finished merging
the 1.6 source into the head, I'll post
I just finished a project where I had to do a fair bit
of performance tuning work over the last year. I was
looking through the current digester source, and even
without torquing the code wierdly or changing class
APIs I've seen places that could probably be made
faster.
1) Would folks be
13 matches
Mail list logo
