Will Glass-Husain wrote: > If you can figure out a simple way of making this compile without > warnings in both JDK 1.3/1.4 and JDK 1.5, I'll patch it. (submit to > Bugzilla).
javac -source 1.3 -target 1.3
will do it. The problem is merely that java 5 assumes a default:
-source 1.5 -target 1.5
But, IMHO, you ought to be going 1.4 compatible anyway. Get those NIO compatible methods into V! :)
PS: in response to someone about NIO, at the moment with a NIO server you have to:
1. Read a buffer from the hard-disk
2. Convert that buffer into characters, by re-reading every element and creating new copies of the data in memory
3. pass the characters to V as a template
4. get the result of the template out of V as characters
5. convert the characters back to bytes, by reading every character and making a new copy as a byte, placing the bytes into a new buffer (you could re-use the old one, but you still have to do the copying)
6. transmit the buffer by pumping the data to the network card
Now, if V were NIO compatible, it could read the byte-buffer directly, and interpret it. That's probably considerable effort (means giving V a translation table so that it converts all the symbols in its grammar into the byte-encoded form of those symbols) - incidentally, it would be potentially considerably faster: doing raw-byte template execution without converting back and forth via a charset.
At the very least, though, it could accept templates as "ByteBuffer + Charset" or "CharBuffer" (means the same thing, in effect) AND modifying the CharBuffer data in-situ (which automatically, via NIO's design, updates the bytes in the ByteBuffer). This would remove one unnecessary complete read of the buffer and one complete read of the character output.
But...what would be far more valuable is if V could "lazily" or "partially" execute templates, which is the philosophy of NIO: do whatever work you can now, and do the rest later, whenever "later" happens to be.
For instance, if I have a template consisting of:
A foreach( blah ) B end C if( something ) D else E end F
Then sections A, C, and F can all be parsed, executed, and returned *immediately* when the server starts. Not only that, but if they were stored in NIO buffers, then the server can actually swap them to disk and later write them directly from disk to the network card (if they are big) without the CPU loading them and without them going into and out of RAM.
Sections D and E can also be done at startup, and the if() then has both branches pre-generated and pre-cached.
Section B, obviously, cannot be executed until the template is used, and has to be re-executed on each use. It can be parsed and held ready using V's template-parse-caching.
Maybe, under the covers, V already executes A, C, D, E, and F when the template is first executed, and stores those String's individually internally, and the next time the template is executed it concatenates them with the freshly-executed B to make the output STring.
However, this is inefficient: each time the template is executed, it's copying the entirety of the pre-generated bits to form a new string. What you really want to do is give the application access to the *references* to the pre-generated bits, so that instead of doing lots of data copying on each subsequent re-execute you can merely return "refA, B, refC, refD, refE" and leave it to the application to send them in series (assuming this is a webserver: in that case, it never needs to make a new String that is the concatenation, it can merely send each lump in series, wihtout ever allocating any extra memory).
NIO has another neat feature, though: it has a method call that will take a set of strings (encoded as ByteBuffers) and transmit them in series, wihtout you even having to manage the transmission. If, for instance, refA is re-used by 99% of your templates then in theory with this gathering-write the OS could pre-cache refA closer to the network card (although I have approximately 0 confidence that any current JVM + OS combination in common usage actually does this).
...
Does any of this matter? How much?
With large templates, it certainly can matter. I don't have a useful test rig to give numbers :( because I don't know how to do a control. What would I do, re-write V using NIO and then give you the numbers? :).
The best thing to do would be for someone to profile V for a few hours, and show where the bottlenecks are; if V is I/O bound then adding NIO and removing excessive data-copying overhead could improve performance considerably, especially with templates copying 10's of kb of data around unnecessarily. If V is processor bound then who's even going to notice the difference if the I/O is sped up?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
