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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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
