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 <[EMAIL PROTECTED]> 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 <[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 > -- http://r-bg.com
