You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by specialist33 <sp...@grexengine.com> on 2003/10/20 22:28:32 UTC
re: NIO and V...
I've searched the archives, but can't find reference to this (Java NIO,
the new I/O routines from 1.4.x). What I'm interested in is integration
between Velocity and NIO...
By way of introduction, I implemented something that is almost identical
to Velocity (before I knew V existed, honest!), but proprietary, except
that output is directly into ByteBuffers (the low-level primitives that
NIO uses exclusively), combined with a very simple lazy execution...the
static parts of the template are converted (and provided) immediately,
whereas all the foreach loops etc are partially converted and stored (in
form similar to a standard parse tree) ready for quick execution later
on. So, where V has one context, I have two - the "static" and
"dynamic". Any expression that can be evaluated without using the
dynamic context is eval'd immediately, anything that uses the dynamic
one is stored for later (lazy) execution.
The point of all this is to have a templating engine that works very
smoothly with NIO, and where as much as possible can go into
ByteBuffer's for (hopefully) optimal transmission when needed. I have a
very simple keyed caching system that allows parse trees to share the
ByteBuffers for any syntactically identical input. (NB: NIO has a method
call to do gathering writes, pulling data from a sequence of ByteBuffers)
So, when I came across V recently, I was delighted - I concur heartily
with 99% of the design of V...my own system is as I said almost
identical (barring syntax), although slightly less feature complete.
However, I'd really prefer not to throw away both the easy NIO
integration and the lazy execution.
Is there anyone interested in helping me modify V to support these
features? I work better with someone to bounce things off :). AFAICS the
output to ByteBuffer's is very little work, and should easily fit in
with the rest of the API (it would just mean an extra version of things
like mergeTemplate that spat out a ByteBuffer), but perhaps the lazy
execution would be much harder; I'd appreciate the co-operation of
someone who understood the V code much better than I.
I don't know whether/how any of this could/should be merged into V's
main code, but I'd like to do so if you felt it was useful. My employers
are also happy for me to work on this at work (they're generally
supportive of anything under the apache/BSD licenses - and would also
prefer us to be using a less proprietary system :)).
Regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: NIO and V...
Posted by specialist33 <sp...@grexengine.com>.
Sorry for the delay in replying - BT cut all our telephone lines
(apparently whilst trying to add a line for someone else) and we've been
disconnected for a few days.
I'm going to try and answer all the related questions in one go - so I'm
afraid this will be a loooong post. Hope it's not confusing.
Claude Brisson wrote:
> how do you distinguish static and dynamic parts in your templates ?
This is actually just confusing the issue right now: I explained that
aspect very badly. I'll have another go later (it's actually an
experimental new idea we've been trying).
Our templating system just assumes:
- all plain text is static
- certain directives always create static content (e.g. content that
may change if you restart the JVM, but otherwise will not change. It
can't be hardcoded, but is guaranteed to be static for the lifetime of
the JVM)
- (experimental: certain directives, depending on their args, create
static content)
- ...all other directives create dynamic content
Gabriel Sidler wrote:
> I assume the purpose of using NIO and static/dynamic evaluation is to
> maximize
> performance. Can you say something about the performance you see in your
> solution and how much performance gain you would expect for Velocity?
>
> A few years ago Velocity was comparable in performance to JSP. This
> is not true anymore. Tests I did showed that today's optimized JSP
> implementations
> (for example the one that comes with Caucho Resin) are 2 to 3 times
faster
> than Velocity. I certainly would welcome a performance boost for
Velocity.
>
NIO ByteBuffers are (can be) a direct source of bytes to be transferred
over the network, unlike say a String which is a wrapper around some
java data that will get passed around a bit in the VM, and be copied a
couple of times before eventually making it to the network-card's
buffers. In theory [*]. According to the API spec:
"Given a direct byte buffer, the Java virtual machine will make a best
effort to perform native I/O operations directly upon it. That is, it
will attempt to avoid copying the buffer's content to (or from) an
intermediate buffer before (or after) each invocation of one of the
underlying operating system's native I/O operations."
So, you prefer to allocate (and fill) buffers early, and keep them
around for a long time. You really want to keep re-using them as much as
possible - and WITHOUT ever cloning them. One thing you can easily do
with the lazy execution scheme is add a fine-grained cache (just a
mapping from parse-tree fragments to ByteBuffers of the output) that
actually caches a ref to the ByteBuffer end result of converting parts
of a template's parse-tree...and even if the original template is so
thoroughly altered that that fragment is now useless, it may actually be
recreated by a future modification to a different template. Ahem. I hope
that makes some sense? It's of no use in short-lived servers, but of
potentially large benefit in long-lived servers.
So, our templating system:
- Reads in every template at startup
- Attempts to convert as much of each template to a BB as possible,
immediately
- When a particular template is fetched, it just converts the
"dynamic" stuff - e.g. most directives - into BB's
- NIO uses gathering writes - so you can pass it an array of BB's
containing your data, and it will read from them sequentially.
Things it could also do, which ought to increase performance in some
cases, but it doesn't do at the moment:
- If the first part of the template was static, so already exists
converted into a BB, start transmitting it BEFORE you've converted the
dynamic stuff. You might well manage to complete the conversion of the
dynamic parts before the static parts have been transferred. This
reduces the client's perceived RTT - the effect on a lightly loaded
server sending small templates is probably statistically insignificant.
On a heavily loaded server, or sending large templates, the effect could
be considerable. Like all server performance though, it's going to
depend on what your server is doing, whether it's bottlenecking on CPU,
network-transmission, local-bus transmission, etc.
Now, as to your benchmarked poor performance...I'm not even going to
begin to guess at the cause of the difference :). I've done enough
server-optimization to know that it's hopeless for me to try, without a
lot more info :(.
How much difference would it make to V? Again, unless I (or someone else
here has already?) does some benchmarking to show to what extent V is
bottlenecking on:
- CPU: executing templates
- CPU: copying data in memory
- LocalBus: copying data to network card
- Network: transmitting data
- ...probably some others. E.g. "Disk: virtual memory/page faults etc"
then I can't say. The 2nd, 3rd and 4th things I've listed can all
benefit from using NIO instead of noraml I/O in java. See below for some
information why, but this is quite a deep topic - there are a *lot* of
performance optimizations built-in to NIO (or made possible by NIO) that
were impossible to reproduce in user code with normal I/O in Java.
Mainly these center around the fact that NIO exposes *direct* access to
system memory - a famous example is that Sun has used NIO to send
texture data directly to a 3D card over the AGP bus, without using JNI
(nb: JNI was needed to get the absolute memory addresses that the AGP
mem was mapped to!) - but once the ByteBuffer was setup, Java could
communicate directly with the 3D card.
Geir Magnusson Jr. wrote:
>
> I guess I don't understand the model. I thought we did a decent job of
> of keeping the static parts simple, and rendering unto Ceasar only that
> which is Ceasar's (sorry..). We can't convert from the strings to bytes
> until we know the encoding that the client wants. I guess you could at
> parse time, if you had an encoding hint ahead of time, do it then,
> saving the encoding step at the cost of memory. It's interesting,
though.
>
When the JVM starts, you know what encoding you are going to use
(typically). E.g. when you startup a webserver, once it's read in it's
config, it typically knows what ISO charsets it's going to use (or, in
many cases, which single charset it will use).
So, currently we take that as an argument - which charset(s) to encode.
We only use one charset, and spawn extra instances of the templating
system if we want to support multiple charsets. This is simply because
it was the least effort, and 99.99% of the time we're *only* using
ISO-8859-1 anyway.
> Also, I'd be loathe to make a version of velocity that only worked with
> JDK 1.4...
...something I can relate to. As I said, I don't know if such
modifications would be welcome.
However, AFAICS, NIO support would merely be an additional / parallel
code path that provided an alternative for the "storing the output"
code. I.e. it makes no changes to the parsing or executing stages - but
where a String is currently produced, a BB would either be created or
written to (typically you try not to create new BB's, but to re-use
instead; IIRC it's the only exception to the offical advice "create as
many object as you like" in the latest JVM's)
A lazy-execution subsystem would, I hope, be isolated to just a small
section of code. Instead of just calling "merge", you might have an
extra arg version which allowed you to choose whether the template was
"merged IMMEDIATELY", or "partially merged".
FYI, currently our equivalent of the "merge" method returns a Vector.
That Vector contains a mixture of String's and ByteBuffer's. String's
are untransformed directives (dynamic stuff) that need to be re-executed
later (i.e. the bits to be executed lazily). BB's are transformed code
that can now be transmitted without further ado.
We have a couple of versions of the merge method, and one takes an input
Vector as arg - it is just a convenience method that scans through the
Vector, checking for any BB instances, and re-executing them by
delegation to the main version of the merge method. It then outputs a
Vector that is guaranteed to only contain BB's.
[*] - However, NIO is still rather platform-specific and poorly
documented by Sun, so the API demands *very* few guarantees (if any)
about how optimized a particular implementation needs to be. For
instance, at one point in the 1.4.2 docs, it says that (paraphrase)
"...a good implementation will not block at all, although some
implementations may block forever at this point...". Sun's current linux
impl blocks forever, and I hear their Solaris one blocks only very
briefly (possible not at all?). So, YMMV quite a lot, and you end up
trying to be as well behaved as possible in an attempt to coerce best
behaviour and performance from your platform.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: NIO and V...
Posted by Claude Brisson <cl...@savoirweb.com>.
how do you distinguish static and dynamic parts in your templates ?
CloD
----- Original Message -----
From: "specialist33" <sp...@grexengine.com>
To: <ve...@jakarta.apache.org>
Sent: lundi 20 octobre 2003 22:28
Subject: re: NIO and V...
> I've searched the archives, but can't find reference to this (Java NIO,
> the new I/O routines from 1.4.x). What I'm interested in is integration
> between Velocity and NIO...
>
> By way of introduction, I implemented something that is almost identical
> to Velocity (before I knew V existed, honest!), but proprietary, except
> that output is directly into ByteBuffers (the low-level primitives that
> NIO uses exclusively), combined with a very simple lazy execution...the
> static parts of the template are converted (and provided) immediately,
> whereas all the foreach loops etc are partially converted and stored (in
> form similar to a standard parse tree) ready for quick execution later
> on. So, where V has one context, I have two - the "static" and
> "dynamic". Any expression that can be evaluated without using the
> dynamic context is eval'd immediately, anything that uses the dynamic
> one is stored for later (lazy) execution.
>
> The point of all this is to have a templating engine that works very
> smoothly with NIO, and where as much as possible can go into
> ByteBuffer's for (hopefully) optimal transmission when needed. I have a
> very simple keyed caching system that allows parse trees to share the
> ByteBuffers for any syntactically identical input. (NB: NIO has a method
> call to do gathering writes, pulling data from a sequence of ByteBuffers)
>
> So, when I came across V recently, I was delighted - I concur heartily
> with 99% of the design of V...my own system is as I said almost
> identical (barring syntax), although slightly less feature complete.
> However, I'd really prefer not to throw away both the easy NIO
> integration and the lazy execution.
>
> Is there anyone interested in helping me modify V to support these
> features? I work better with someone to bounce things off :). AFAICS the
> output to ByteBuffer's is very little work, and should easily fit in
> with the rest of the API (it would just mean an extra version of things
> like mergeTemplate that spat out a ByteBuffer), but perhaps the lazy
> execution would be much harder; I'd appreciate the co-operation of
> someone who understood the V code much better than I.
>
> I don't know whether/how any of this could/should be merged into V's
> main code, but I'd like to do so if you felt it was useful. My employers
> are also happy for me to work on this at work (they're generally
> supportive of anything under the apache/BSD licenses - and would also
> prefer us to be using a less proprietary system :)).
>
> Regards.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: NIO and V...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Tuesday, October 21, 2003, at 01:51 PM, Gabriel Sidler wrote:
> Your assumption seems to be that the NIO package would be used for the
> web server to web client
> communication.
> I don't think that was the idea. The way I understood specialist33's
> mail was that he
> uses NIO to speed up file I/O and caching performance on the server.
>
That wasn't my read, but that we'd support it somehow in the rendering
process. But I'll wait for the answer to your question below...
> I am wondering if and how much speed up could be achieved by this
> approach. Specialist33 can you
> elaborate?
>
> Gabe
>
> PS: http://java.sun.com/j2se/1.4.2/docs/guide/nio/
>
>
>
>
>
> Claude Brisson wrote:
>
>> yes such optimizations would be welcome - at least informations about
>> where they occur
>>
>> but NIO means several streams, and some format information so that
>> the client side is able to assemble the puzzle back, as does the
>> frameset tag or urls in image or javascript or other html elements.
>>
>> i mean : the textual flow is an unreakable stream until you have some
>> textual elements to identify synchronous and asynchronous
>> parts, hence my question.
>>
>> IMO, NIO has nothing to do with the desirable optimizations you are
>> speaking about
>>
>> CloD
>>
>> ----- Original Message -----
>> From: "Gabriel Sidler" <si...@teamup.com>
>> To: "Velocity Developers List" <ve...@jakarta.apache.org>
>> Sent: mardi 21 octobre 2003 06:51
>> Subject: Re: NIO and V...
>>
>>
>>
>>> I assume the purpose of using NIO and static/dynamic evaluation is to
>>> maximize
>>> performance. Can you say something about the performance you see in
>>> your
>>> solution and how much performance gain you would expect for Velocity?
>>>
>>> A few years ago Velocity was comparable in performance to JSP. This
>>> is not true anymore. Tests I did showed that today's optimized JSP
>>> implementations
>>> (for example the one that comes with Caucho Resin) are 2 to 3 times
>>> faster
>>> than Velocity. I certainly would welcome a performance boost for
>>> Velocity.
>>>
>>> Gabe
>>>
>>>
>>> specialist33 wrote:
>>>
>>>
>>>> I've searched the archives, but can't find reference to this (Java
>>>> NIO, the new I/O routines from 1.4.x). What I'm interested in is
>>>> integration between Velocity and NIO...
>>>>
>>>> By way of introduction, I implemented something that is almost
>>>> identical to Velocity (before I knew V existed, honest!), but
>>>> proprietary, except that output is directly into ByteBuffers (the
>>>> low-level primitives that NIO uses exclusively), combined with a
>>>> very
>>>> simple lazy execution...the static parts of the template are
>>>> converted
>>>> (and provided) immediately, whereas all the foreach loops etc are
>>>> partially converted and stored (in form similar to a standard parse
>>>> tree) ready for quick execution later on. So, where V has one
>>>> context,
>>>> I have two - the "static" and "dynamic". Any expression that can be
>>>> evaluated without using the dynamic context is eval'd immediately,
>>>> anything that uses the dynamic one is stored for later (lazy)
>>>> execution.
>>>>
>>>> The point of all this is to have a templating engine that works very
>>>> smoothly with NIO, and where as much as possible can go into
>>>> ByteBuffer's for (hopefully) optimal transmission when needed. I
>>>> have
>>>> a very simple keyed caching system that allows parse trees to share
>>>> the ByteBuffers for any syntactically identical input. (NB: NIO has
>>>> a
>>>> method call to do gathering writes, pulling data from a sequence of
>>>> ByteBuffers)
>>>>
>>>> So, when I came across V recently, I was delighted - I concur
>>>> heartily
>>>> with 99% of the design of V...my own system is as I said almost
>>>> identical (barring syntax), although slightly less feature complete.
>>>> However, I'd really prefer not to throw away both the easy NIO
>>>> integration and the lazy execution.
>>>>
>>>> Is there anyone interested in helping me modify V to support these
>>>> features? I work better with someone to bounce things off :). AFAICS
>>>> the output to ByteBuffer's is very little work, and should easily
>>>> fit
>>>> in with the rest of the API (it would just mean an extra version of
>>>> things like mergeTemplate that spat out a ByteBuffer), but perhaps
>>>> the
>>>> lazy execution would be much harder; I'd appreciate the co-operation
>>>> of someone who understood the V code much better than I.
>>>>
>>>> I don't know whether/how any of this could/should be merged into V's
>>>> main code, but I'd like to do so if you felt it was useful. My
>>>> employers are also happy for me to work on this at work (they're
>>>> generally supportive of anything under the apache/BSD licenses - and
>>>> would also prefer us to be using a less proprietary system :)).
>>>>
>>>> Regards.
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:
>>>> velocity-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>>
>>
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: NIO and V...
Posted by Gabriel Sidler <si...@teamup.com>.
Your assumption seems to be that the NIO package would be used for the
web server to web client
communication. I don't think that was the idea. The way I understood
specialist33's mail was that he
uses NIO to speed up file I/O and caching performance on the server.
I am wondering if and how much speed up could be achieved by this
approach. Specialist33 can you
elaborate?
Gabe
PS: http://java.sun.com/j2se/1.4.2/docs/guide/nio/
Claude Brisson wrote:
>yes such optimizations would be welcome - at least informations about where they occur
>
>but NIO means several streams, and some format information so that the client side is able to assemble the puzzle back, as does the
>frameset tag or urls in image or javascript or other html elements.
>
>i mean : the textual flow is an unreakable stream until you have some textual elements to identify synchronous and asynchronous
>parts, hence my question.
>
>IMO, NIO has nothing to do with the desirable optimizations you are speaking about
>
>CloD
>
>----- Original Message -----
>From: "Gabriel Sidler" <si...@teamup.com>
>To: "Velocity Developers List" <ve...@jakarta.apache.org>
>Sent: mardi 21 octobre 2003 06:51
>Subject: Re: NIO and V...
>
>
>
>
>>I assume the purpose of using NIO and static/dynamic evaluation is to
>>maximize
>>performance. Can you say something about the performance you see in your
>>solution and how much performance gain you would expect for Velocity?
>>
>>A few years ago Velocity was comparable in performance to JSP. This
>>is not true anymore. Tests I did showed that today's optimized JSP
>>implementations
>>(for example the one that comes with Caucho Resin) are 2 to 3 times faster
>>than Velocity. I certainly would welcome a performance boost for Velocity.
>>
>>Gabe
>>
>>
>>specialist33 wrote:
>>
>>
>>
>>>I've searched the archives, but can't find reference to this (Java
>>>NIO, the new I/O routines from 1.4.x). What I'm interested in is
>>>integration between Velocity and NIO...
>>>
>>>By way of introduction, I implemented something that is almost
>>>identical to Velocity (before I knew V existed, honest!), but
>>>proprietary, except that output is directly into ByteBuffers (the
>>>low-level primitives that NIO uses exclusively), combined with a very
>>>simple lazy execution...the static parts of the template are converted
>>>(and provided) immediately, whereas all the foreach loops etc are
>>>partially converted and stored (in form similar to a standard parse
>>>tree) ready for quick execution later on. So, where V has one context,
>>>I have two - the "static" and "dynamic". Any expression that can be
>>>evaluated without using the dynamic context is eval'd immediately,
>>>anything that uses the dynamic one is stored for later (lazy) execution.
>>>
>>>The point of all this is to have a templating engine that works very
>>>smoothly with NIO, and where as much as possible can go into
>>>ByteBuffer's for (hopefully) optimal transmission when needed. I have
>>>a very simple keyed caching system that allows parse trees to share
>>>the ByteBuffers for any syntactically identical input. (NB: NIO has a
>>>method call to do gathering writes, pulling data from a sequence of
>>>ByteBuffers)
>>>
>>>So, when I came across V recently, I was delighted - I concur heartily
>>>with 99% of the design of V...my own system is as I said almost
>>>identical (barring syntax), although slightly less feature complete.
>>>However, I'd really prefer not to throw away both the easy NIO
>>>integration and the lazy execution.
>>>
>>>Is there anyone interested in helping me modify V to support these
>>>features? I work better with someone to bounce things off :). AFAICS
>>>the output to ByteBuffer's is very little work, and should easily fit
>>>in with the rest of the API (it would just mean an extra version of
>>>things like mergeTemplate that spat out a ByteBuffer), but perhaps the
>>>lazy execution would be much harder; I'd appreciate the co-operation
>>>of someone who understood the V code much better than I.
>>>
>>>I don't know whether/how any of this could/should be merged into V's
>>>main code, but I'd like to do so if you felt it was useful. My
>>>employers are also happy for me to work on this at work (they're
>>>generally supportive of anything under the apache/BSD licenses - and
>>>would also prefer us to be using a less proprietary system :)).
>>>
>>>Regards.
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
>
>
>
Re: NIO and V...
Posted by Claude Brisson <cl...@savoirweb.com>.
yes such optimizations would be welcome - at least informations about where they occur
but NIO means several streams, and some format information so that the client side is able to assemble the puzzle back, as does the
frameset tag or urls in image or javascript or other html elements.
i mean : the textual flow is an unreakable stream until you have some textual elements to identify synchronous and asynchronous
parts, hence my question.
IMO, NIO has nothing to do with the desirable optimizations you are speaking about
CloD
----- Original Message -----
From: "Gabriel Sidler" <si...@teamup.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: mardi 21 octobre 2003 06:51
Subject: Re: NIO and V...
> I assume the purpose of using NIO and static/dynamic evaluation is to
> maximize
> performance. Can you say something about the performance you see in your
> solution and how much performance gain you would expect for Velocity?
>
> A few years ago Velocity was comparable in performance to JSP. This
> is not true anymore. Tests I did showed that today's optimized JSP
> implementations
> (for example the one that comes with Caucho Resin) are 2 to 3 times faster
> than Velocity. I certainly would welcome a performance boost for Velocity.
>
> Gabe
>
>
> specialist33 wrote:
>
> > I've searched the archives, but can't find reference to this (Java
> > NIO, the new I/O routines from 1.4.x). What I'm interested in is
> > integration between Velocity and NIO...
> >
> > By way of introduction, I implemented something that is almost
> > identical to Velocity (before I knew V existed, honest!), but
> > proprietary, except that output is directly into ByteBuffers (the
> > low-level primitives that NIO uses exclusively), combined with a very
> > simple lazy execution...the static parts of the template are converted
> > (and provided) immediately, whereas all the foreach loops etc are
> > partially converted and stored (in form similar to a standard parse
> > tree) ready for quick execution later on. So, where V has one context,
> > I have two - the "static" and "dynamic". Any expression that can be
> > evaluated without using the dynamic context is eval'd immediately,
> > anything that uses the dynamic one is stored for later (lazy) execution.
> >
> > The point of all this is to have a templating engine that works very
> > smoothly with NIO, and where as much as possible can go into
> > ByteBuffer's for (hopefully) optimal transmission when needed. I have
> > a very simple keyed caching system that allows parse trees to share
> > the ByteBuffers for any syntactically identical input. (NB: NIO has a
> > method call to do gathering writes, pulling data from a sequence of
> > ByteBuffers)
> >
> > So, when I came across V recently, I was delighted - I concur heartily
> > with 99% of the design of V...my own system is as I said almost
> > identical (barring syntax), although slightly less feature complete.
> > However, I'd really prefer not to throw away both the easy NIO
> > integration and the lazy execution.
> >
> > Is there anyone interested in helping me modify V to support these
> > features? I work better with someone to bounce things off :). AFAICS
> > the output to ByteBuffer's is very little work, and should easily fit
> > in with the rest of the API (it would just mean an extra version of
> > things like mergeTemplate that spat out a ByteBuffer), but perhaps the
> > lazy execution would be much harder; I'd appreciate the co-operation
> > of someone who understood the V code much better than I.
> >
> > I don't know whether/how any of this could/should be merged into V's
> > main code, but I'd like to do so if you felt it was useful. My
> > employers are also happy for me to work on this at work (they're
> > generally supportive of anything under the apache/BSD licenses - and
> > would also prefer us to be using a less proprietary system :)).
> >
> > Regards.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: NIO and V...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Tuesday, October 21, 2003, at 12:51 AM, Gabriel Sidler wrote:
> I assume the purpose of using NIO and static/dynamic evaluation is to
> maximize
> performance. Can you say something about the performance you see in
> your
> solution and how much performance gain you would expect for Velocity?
>
> A few years ago Velocity was comparable in performance to JSP. This
> is not true anymore. Tests I did showed that today's optimized JSP
> implementations
> (for example the one that comes with Caucho Resin) are 2 to 3 times
> faster
> than Velocity. I certainly would welcome a performance boost for
> Velocity.
That's interesting. I wonder where the speed is coming from. I can't
believe it's the I/O part.
>
> Gabe
>
>
> specialist33 wrote:
>
>> I've searched the archives, but can't find reference to this (Java
>> NIO, the new I/O routines from 1.4.x). What I'm interested in is
>> integration between Velocity and NIO...
>>
>> By way of introduction, I implemented something that is almost
>> identical to Velocity (before I knew V existed, honest!), but
>> proprietary, except that output is directly into ByteBuffers (the
>> low-level primitives that NIO uses exclusively), combined with a very
>> simple lazy execution...the static parts of the template are
>> converted (and provided) immediately, whereas all the foreach loops
>> etc are partially converted and stored (in form similar to a standard
>> parse tree) ready for quick execution later on. So, where V has one
>> context, I have two - the "static" and "dynamic". Any expression that
>> can be evaluated without using the dynamic context is eval'd
>> immediately, anything that uses the dynamic one is stored for later
>> (lazy) execution.
>>
>> The point of all this is to have a templating engine that works very
>> smoothly with NIO, and where as much as possible can go into
>> ByteBuffer's for (hopefully) optimal transmission when needed. I have
>> a very simple keyed caching system that allows parse trees to share
>> the ByteBuffers for any syntactically identical input. (NB: NIO has a
>> method call to do gathering writes, pulling data from a sequence of
>> ByteBuffers)
>>
>> So, when I came across V recently, I was delighted - I concur
>> heartily with 99% of the design of V...my own system is as I said
>> almost identical (barring syntax), although slightly less feature
>> complete. However, I'd really prefer not to throw away both the easy
>> NIO integration and the lazy execution.
>>
>> Is there anyone interested in helping me modify V to support these
>> features? I work better with someone to bounce things off :). AFAICS
>> the output to ByteBuffer's is very little work, and should easily fit
>> in with the rest of the API (it would just mean an extra version of
>> things like mergeTemplate that spat out a ByteBuffer), but perhaps
>> the lazy execution would be much harder; I'd appreciate the
>> co-operation of someone who understood the V code much better than I.
>>
>> I don't know whether/how any of this could/should be merged into V's
>> main code, but I'd like to do so if you felt it was useful. My
>> employers are also happy for me to work on this at work (they're
>> generally supportive of anything under the apache/BSD licenses - and
>> would also prefer us to be using a less proprietary system :)).
>>
>> Regards.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: NIO and V...
Posted by Gabriel Sidler <si...@teamup.com>.
I assume the purpose of using NIO and static/dynamic evaluation is to
maximize
performance. Can you say something about the performance you see in your
solution and how much performance gain you would expect for Velocity?
A few years ago Velocity was comparable in performance to JSP. This
is not true anymore. Tests I did showed that today's optimized JSP
implementations
(for example the one that comes with Caucho Resin) are 2 to 3 times faster
than Velocity. I certainly would welcome a performance boost for Velocity.
Gabe
specialist33 wrote:
> I've searched the archives, but can't find reference to this (Java
> NIO, the new I/O routines from 1.4.x). What I'm interested in is
> integration between Velocity and NIO...
>
> By way of introduction, I implemented something that is almost
> identical to Velocity (before I knew V existed, honest!), but
> proprietary, except that output is directly into ByteBuffers (the
> low-level primitives that NIO uses exclusively), combined with a very
> simple lazy execution...the static parts of the template are converted
> (and provided) immediately, whereas all the foreach loops etc are
> partially converted and stored (in form similar to a standard parse
> tree) ready for quick execution later on. So, where V has one context,
> I have two - the "static" and "dynamic". Any expression that can be
> evaluated without using the dynamic context is eval'd immediately,
> anything that uses the dynamic one is stored for later (lazy) execution.
>
> The point of all this is to have a templating engine that works very
> smoothly with NIO, and where as much as possible can go into
> ByteBuffer's for (hopefully) optimal transmission when needed. I have
> a very simple keyed caching system that allows parse trees to share
> the ByteBuffers for any syntactically identical input. (NB: NIO has a
> method call to do gathering writes, pulling data from a sequence of
> ByteBuffers)
>
> So, when I came across V recently, I was delighted - I concur heartily
> with 99% of the design of V...my own system is as I said almost
> identical (barring syntax), although slightly less feature complete.
> However, I'd really prefer not to throw away both the easy NIO
> integration and the lazy execution.
>
> Is there anyone interested in helping me modify V to support these
> features? I work better with someone to bounce things off :). AFAICS
> the output to ByteBuffer's is very little work, and should easily fit
> in with the rest of the API (it would just mean an extra version of
> things like mergeTemplate that spat out a ByteBuffer), but perhaps the
> lazy execution would be much harder; I'd appreciate the co-operation
> of someone who understood the V code much better than I.
>
> I don't know whether/how any of this could/should be merged into V's
> main code, but I'd like to do so if you felt it was useful. My
> employers are also happy for me to work on this at work (they're
> generally supportive of anything under the apache/BSD licenses - and
> would also prefer us to be using a less proprietary system :)).
>
> Regards.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: NIO and V...
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, October 20, 2003, at 04:28 PM, specialist33 wrote:
> I've searched the archives, but can't find reference to this (Java
> NIO, the new I/O routines from 1.4.x). What I'm interested in is
> integration between Velocity and NIO...
>
> By way of introduction, I implemented something that is almost
> identical to Velocity (before I knew V existed, honest!), but
> proprietary, except that output is directly into ByteBuffers (the
> low-level primitives that NIO uses exclusively), combined with a very
> simple lazy execution...the static parts of the template are converted
> (and provided) immediately, whereas all the foreach loops etc are
> partially converted and stored (in form similar to a standard parse
> tree) ready for quick execution later on. So, where V has one context,
> I have two - the "static" and "dynamic". Any expression that can be
> evaluated without using the dynamic context is eval'd immediately,
> anything that uses the dynamic one is stored for later (lazy)
> execution.
>
> The point of all this is to have a templating engine that works very
> smoothly with NIO, and where as much as possible can go into
> ByteBuffer's for (hopefully) optimal transmission when needed. I have
> a very simple keyed caching system that allows parse trees to share
> the ByteBuffers for any syntactically identical input. (NB: NIO has a
> method call to do gathering writes, pulling data from a sequence of
> ByteBuffers)
>
> So, when I came across V recently, I was delighted - I concur heartily
> with 99% of the design of V...my own system is as I said almost
> identical (barring syntax), although slightly less feature complete.
> However, I'd really prefer not to throw away both the easy NIO
> integration and the lazy execution.
>
> Is there anyone interested in helping me modify V to support these
> features? I work better with someone to bounce things off :). AFAICS
> the output to ByteBuffer's is very little work, and should easily fit
> in with the rest of the API (it would just mean an extra version of
> things like mergeTemplate that spat out a ByteBuffer), but perhaps the
> lazy execution would be much harder; I'd appreciate the co-operation
> of someone who understood the V code much better than I.
>
> I don't know whether/how any of this could/should be merged into V's
> main code, but I'd like to do so if you felt it was useful. My
> employers are also happy for me to work on this at work (they're
> generally supportive of anything under the apache/BSD licenses - and
> would also prefer us to be using a less proprietary system :)).
>
I guess I don't understand the model. I thought we did a decent job of
of keeping the static parts simple, and rendering unto Ceasar only that
which is Ceasar's (sorry..). We can't convert from the strings to
bytes until we know the encoding that the client wants. I guess you
could at parse time, if you had an encoding hint ahead of time, do it
then, saving the encoding step at the cost of memory. It's
interesting, though.
Also, I'd be loathe to make a version of velocity that only worked with
JDK 1.4...
> Regards.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org