santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raul Benito" <r...@apache.org>
Subject Re: Benchmarks?
Date Thu, 27 Sep 2007 21:59:26 GMT
Hi Jason,
I understand your concerns, and I think you are right stating that
in1.6this optimization is unneeded and even can be a small
pesimization (I don't
think it so extreme but I don't have data to back-up). But I have numbers
that show that 1.4 is a nice optimization and if you go to j2me it is even
better. As we still have people with 1.4 JVM (we have 1.3 compatibility yet)
I think we should keep this small hack.

But anyway I'm more than open to find a common path that works well in new
and old machines. And also I think there are more paths to optimize.

Regards,

Raul

On 9/27/07, jason marshall <jdmarshall@gmail.com> wrote:
>
> I know this is an old thread, but I thought I would share what I
> found, since I can't share code.
>
>
> The UnsynchBufferedOutputStream usage in calculateDigest seems
> superfluous to me.  I think if you look carefully at
> XMLSignatureInput, you'll find that all but one path is using block
> I/O already.  Doubling up block and buffered I/O just makes heavy
> lifting paths slower, not faster, even with the shortcuts for large
> blocks.
>
> More generally, I think the utility of UnsynchBufferedOutputStream is
> essentially less than zero at this point.  I suspect you'll find that
> under JDK 1.5 or later, you can't perceive a noteworthy difference
> between this class and BufferedInputStream, when used as it is used
> here.  I wouldn't be shocked to discover that you're actually getting
> worse performance than BufferedOutputStream, having hurt your
> performance by bifurcating the code paths that Hotspot has to
> investigate.  Only under JDK 1.4 does this code still genuinely
> accomplish something, and I'm not convinced the added complexity is
> worth that gain.
>
> -Jason
>
> On 4/9/07, Raul Benito <raul@apache.org> wrote:
> > There is no such thing as xml security benchmark, I try to do one myself
> > several time, but the lack of time always made me postpone.
> > In order to test my changes I use a slightly modified copy of the old
> > xmlbench, it only tests inclusive-c14n and enveloping signatures. But it
> > works for seeing what can be optimized.
> > I also test again time completion of our test suite, but this becoming
> more
> > difficult. Because it use to take 120 seconds to run, now it only takes
> 2-3
> > and the speed improvements are harder to see.
> >
> > You can also try a loop of several thousands verification and decoding.
> So
> > you can try to measure the speed up.
> >
> > If I can help you, don't hesitate in asking.
> >
> > Regards,
> >
> > Raul
> >
> >
> >
> > On 4/7/07, jason marshall < jdmarshall@gmail.com> wrote:
> > > There's a spot in the MessageDigest calculations where all but one
> > > path through the code doubles up Buffered I/O and Block I/O.  I've
> > > been working on a patch to hoist the buffering into the one path that
> > > needs it.  This gives my path a nice little throughput boost, but I'm
> > > wondering if I've caused regressions along the other paths.
> > >
> > > Raul, do you have a set of benchmarks you were using when doing the
> > > 1.4 tuning work?  Before I try to push a patch through the complicated
> > > IP system at work, I'd like to have an idea if it will get accepted or
> > > not.
> > >
> > > --
> > > - Jason
> > >
> >
> >
> >
> > --
> > http://r-bg.com
>
>
> --
> - Jason
>



-- 
http://r-bg.com

Mime
View raw message