I'm impressed ! Did I mentioned that I love working on tomcat ( even with all the flames and 'issues' and politics ) ?
On Thu, 13 Jun 2002, Mladen Turk wrote: > I've seen in the JNI aprImpl the JK_DIRECT_BUFFER_NIO flag that is newer > used. What's missing ( the most ) is a MsgAjp and MessageBytes impl. with a NIO ByteBuffer instead of byte[] as backend. I already put the hooks to allow a different version of MessageBytes to be used ( well, at least I tried to cover this extension - it may need some adjustmentes to deal with the conditioanl compilation ). > IMO the purpose would be to use the java.nio. Package available in the > java 1.4 and JNI 1.4 specification. Yes, if JDK1.4 is detected we should use NIO, and if not we should fall back. That was the plan - but your tests seem to change that. > Don't know if the testing code is valid but briefly here are some facts. > > The direct buffering is slower (!) then standard byte array if there is > no copy, but faster about 20% if the array gets copied. I assume you compare direct buffer with getByteArrayElements() with pinning ??? And the direct buffer is slower ??? > The most important thing that bothers me is that the java is more then 2 > times slower then the GetByteArrayRegion version. Not sure I understand. GetByteArrayRegion is supposed to be the slower that GetByteArryaElements if pinning works, and much slower than NIO, at least for any large ( ? ) buffer. At least that's (my) commons sense. > Now, I allway tought that JNI calls imposes serious performance > degradation, but I'm not so sure now. All my tests show that JNI has serious problems - mostly related with strings and buffer allocation/memcpy/etc. Using 'straight' JNI ( i.e. as in the book ) is horrible. But so far the buffer tricks seem to work - at least in my tests, and it seems others ( the mozilla blackwood ) are doing the same. It is possible that NIO has some bugs, but I can't see how they can mess it that badly to make it slower than GetByteArrayRegion or pinning. It's worth investigating - I was planning to work on that after we get a release out, but I'll try to find few hours. ( but first I have to compile some jsps :-) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
