You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Christian Trutz <ve...@smilebase.de> on 2002/03/13 08:26:14 UTC
Velocity Compiler
Hello Velocity community,
I am new to this mailing list, my name is Christian Trutz and I am a graduate
student (mathematics) at University Bonn in Germany. Velocity is for me a
cool and useful tool and I want to contribute a little.
In the actual CVS tree there is a incomplete
org.apache.velocity.runtime.compile.Compiler class. This class wants to
compile a template via BCEL. I think it's better to generate first a java
file and then compile this with an usual compiler. What I mean:
Velocity file:
-----------
Hello $foo
-----------
after "compilation" you get something like this:
----------------------------------------------------------
public class CompiledTemplate {
public void merge( Context context, Writer writer) {
writer.write("Hello ");
writer.write( context.get( "foo" ) );
}
}
--------------------------------------------------------
Is this a good idea???
Is anybody working on a Velocity template compiler?
The AST (see JJTree) implemets the visitor pattern and any AST node has a
render method ... why? Is rendering with a visitor not so good?
Christian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-03-13 at 02:26, Christian Trutz wrote:
> Is anybody working on a Velocity template compiler?
>
> The AST (see JJTree) implemets the visitor pattern and any AST node has a
> render method ... why? Is rendering with a visitor not so good?
I believed that the visitor might be slower so I made the tree self
walking. I took the suggestion from Bob McWhirter and Terence Parr at
the time. Terence Parr is the Antlr author.
>
> Christian
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> On Wed, 2002-03-13 at 02:26, Christian Trutz wrote:
>> In the actual CVS tree there is a incomplete
>> org.apache.velocity.runtime.compile.Compiler class. This class wants to
>> compile a template via BCEL. I think it's better to generate first a java
>> file and then compile this with an usual compiler. What I mean:
>>
>>
>> Velocity file:
>> -----------
>> Hello $foo
>> -----------
>>
>> after "compilation" you get something like this:
>>
>> ----------------------------------------------------------
>> public class CompiledTemplate {
>>
>> public void merge( Context context, Writer writer) {
>>
>> writer.write("Hello ");
>> writer.write( context.get( "foo" ) );
>> }
>> }
>> --------------------------------------------------------
>
> I disagree, you're going to get into all the nasty problems of
> generating source and compiling the sources in your deployed
> environment.
Indeed. Syntax aside (heh), the compilation phase is one of the
nastiest parts of implementing a JSP engine. Just look at the JSP
portion of Tomcat for an example (and that's not bad code, either).
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Jason van Zyl <jv...@zenplex.com>.
On Thu, 2002-03-14 at 08:18, Geir Magnusson Jr. wrote:
> On 3/14/02 2:53 AM, "Christian Trutz" <ch...@smilebase.de> wrote:
...
>
> That's fine - that's the simple case though. If I have
>
> $person.foo
>
> Velocity is required to try
>
> $person.get("foo")
> $person.getFoo()
> $person.getfoo()
> $person.isFoo()
Yes, velocity is required to but in reality the majority of the time
only one of those four options is actually employed. That's still my
argument and that if it was stated somewhere that this is how the
templates were made then after the method required to render that
$person.foo reference is discovered it could be used to generate
bytecode. You would have to check for problems during development but as
deployment rolled around you would be assured the compiler would work.
All I'm saying is that the free willy and the immutable type approach
would work.
> Of course, you can express that easily in bytecode (lets face it, our code
> compiles... :)
>
> This feature is very valuable in separating the view expressed in the
> template from the datamodel expressed as objects in the context...
I don't think it really has anything to do with separation per se. If
part of your model includes mutable types then there is probably
something wrong with your model which is what I've always contended. I
don't expect to garner any favour with this view all I'm saying is that
the expectation of immutable types in the context to produce bytecode is
possible and I think it would be faster. But as mentioned in a previous
message I'll let it rested until I actually have something working.
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> The bytecodes are language independent. - Sam Ruby
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
AW: Velocity Compiler
Posted by Christian Trutz <ch...@smilebase.de>.
>>> I have thought about it a lot but haven't done much. Also realize that
>>> with the current internal structure of velocity it is not possible to
>>> make an efficient compiler because the types of the objects in the
>>> context are not assumed to be static. By that I mean if you 'person' in
>>> the context, during one rendering that can be a Person object, but on
>>> the next it can be a Hashtable.
>>
>> Oh, I think, it doesn't matter if $person is a Person or a HashTable,
why
>> it's not correct to handle this like:
>>
>> ...
>> Object person = context.get( "person" );
>> writer.write( person != null ? person.toString() : "$person" );
>> ...
>
>That's fine - that's the simple case though. If I have
>
> $person.foo
>
>Velocity is required to try
>
> $person.get("foo")
> $person.getFoo()
> $person.getfoo()
> $person.isFoo()
>
>Of course, you can express that easily in bytecode (lets face it, our code
>compiles... :)
>
>This feature is very valuable in separating the view expressed in the
>template from the datamodel expressed as objects in the context...
>
Oh, now I understand the problem, the magic word in this situation is of
course "reflection" ...
Christian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/14/02 2:53 AM, "Christian Trutz" <ch...@smilebase.de> wrote:
>
>
> [SNIP]
>> I disagree, you're going to get into all the nasty problems of
>> generating source and compiling the sources in your deployed
>> environment.
>
> OK, I don't have experience with such problems ...
>
> [SNAP]
>> I have thought about it a lot but haven't done much. Also realize that
>> with the current internal structure of velocity it is not possible to
>> make an efficient compiler because the types of the objects in the
>> context are not assumed to be static. By that I mean if you 'person' in
>> the context, during one rendering that can be a Person object, but on
>> the next it can be a Hashtable.
>
> Oh, I think, it doesn't matter if $person is a Person or a HashTable, why
> it's not correct to handle this like:
>
> ...
> Object person = context.get( "person" );
> writer.write( person != null ? person.toString() : "$person" );
> ...
That's fine - that's the simple case though. If I have
$person.foo
Velocity is required to try
$person.get("foo")
$person.getFoo()
$person.getfoo()
$person.isFoo()
Of course, you can express that easily in bytecode (lets face it, our code
compiles... :)
This feature is very valuable in separating the view expressed in the
template from the datamodel expressed as objects in the context...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
The bytecodes are language independent. - Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Christian Trutz <ch...@smilebase.de>.
[SNIP]
> I disagree, you're going to get into all the nasty problems of
> generating source and compiling the sources in your deployed
> environment.
OK, I don't have experience with such problems ...
[SNAP]
> I have thought about it a lot but haven't done much. Also realize that
> with the current internal structure of velocity it is not possible to
> make an efficient compiler because the types of the objects in the
> context are not assumed to be static. By that I mean if you 'person' in
> the context, during one rendering that can be a Person object, but on
> the next it can be a Hashtable.
Oh, I think, it doesn't matter if $person is a Person or a HashTable, why
it's not correct to handle this like:
...
Object person = context.get( "person" );
writer.write( person != null ? person.toString() : "$person" );
...
???
Christian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-03-13 at 02:26, Christian Trutz wrote:
> Hello Velocity community,
>
> I am new to this mailing list, my name is Christian Trutz and I am a graduate
> student (mathematics) at University Bonn in Germany. Velocity is for me a
> cool and useful tool and I want to contribute a little.
>
> In the actual CVS tree there is a incomplete
> org.apache.velocity.runtime.compile.Compiler class. This class wants to
> compile a template via BCEL. I think it's better to generate first a java
> file and then compile this with an usual compiler. What I mean:
>
>
> Velocity file:
> -----------
> Hello $foo
> -----------
>
> after "compilation" you get something like this:
>
> ----------------------------------------------------------
> public class CompiledTemplate {
>
> public void merge( Context context, Writer writer) {
>
> writer.write("Hello ");
> writer.write( context.get( "foo" ) );
> }
> }
> --------------------------------------------------------
I disagree, you're going to get into all the nasty problems of
generating source and compiling the sources in your deployed
environment.
> Is this a good idea???
>
> Is anybody working on a Velocity template compiler?
I have thought about it a lot but haven't done much. Also realize that
with the current internal structure of velocity it is not possible to
make an efficient compiler because the types of the objects in the
context are not assumed to be static. By that I mean if you 'person' in
the context, during one rendering that can be a Person object, but on
the next it can be a Hashtable.
So you could make a compiler but there is a severe limitation.
> The AST (see JJTree) implemets the visitor pattern and any AST node has a
> render method ... why? Is rendering with a visitor not so good?
>
>
> Christian
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Jason van Zyl <jv...@zenplex.com>.
On Thu, 2002-03-14 at 04:51, Attila Szegedi wrote:
> ----- Original Message -----
> From: "Jason van Zyl" <jv...@zenplex.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: 2002. március 13. 18:55
> Subject: Re: Velocity Compiler
>
>
> > On Wed, 2002-03-13 at 05:19, Geir Magnusson Jr. wrote:
> >
> > >
> > > I guess the question is - is there any point to doing this? :) It's not
> > > clear to me what kind of real performance improvements can be realized
> by
> > > compiling, because once the template is intepreted, it's bytecode,
> right?
> >
> > The AST is bytecode, but I believe the compiled form of a template would
> > be different in that the reflection would be removed and if types place
> > in the context were immutable then I believe the compiler would make
> > things faster.
> >
>
> This simply can't be done without seriously limiting Velocity functionality.
I honestly don't believe so. I certainly wouldn't make the immutability
mandatory but I still believe that the types in the context don't change
for the most part.
> For *full* compilation into bytecode, you need a strongly typed language,
> and not the loosely typed scripting-language like philosophy Velocity
> sports, period. The Tea template engine compiles to bytecode, and its syntax
> indeed features strongly typed template variables.
I believe that both methods could work. But I haven't had time to play
around and won't for a while so I won't bring it up again until I have
it working ;-)
> Cheers,
> Attila.
>
> --
> Attila Szegedi
> home: http://www.szegedi.org
>
>
> > --
> > jvz.
> >
> > Jason van Zyl
> > jvanzyl@apache.org
> >
> > http://tambora.zenplex.org
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Attila Szegedi <sz...@freemail.hu>.
----- Original Message -----
From: "Jason van Zyl" <jv...@zenplex.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: 2002. március 13. 18:55
Subject: Re: Velocity Compiler
> On Wed, 2002-03-13 at 05:19, Geir Magnusson Jr. wrote:
>
> >
> > I guess the question is - is there any point to doing this? :) It's not
> > clear to me what kind of real performance improvements can be realized
by
> > compiling, because once the template is intepreted, it's bytecode,
right?
>
> The AST is bytecode, but I believe the compiled form of a template would
> be different in that the reflection would be removed and if types place
> in the context were immutable then I believe the compiler would make
> things faster.
>
This simply can't be done without seriously limiting Velocity functionality.
For *full* compilation into bytecode, you need a strongly typed language,
and not the loosely typed scripting-language like philosophy Velocity
sports, period. The Tea template engine compiles to bytecode, and its syntax
indeed features strongly typed template variables.
Cheers,
Attila.
--
Attila Szegedi
home: http://www.szegedi.org
> --
> jvz.
>
> Jason van Zyl
> jvanzyl@apache.org
>
> http://tambora.zenplex.org
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/14/02 3:08 AM, "Christian Trutz" <ch...@smilebase.de> wrote:
> [SNIP]
>>> to velocity would be required in order to make this actually work. A
>>> core that stated immutable types in the context which would allow for
>>> real complication with the option to allow mutable types if you wished.
>>> Hashtables are convenient and I know people use them but I think that
>>> allow mutable types in the context actually promotes bad design.
>>
>> How's that? When you see
>>
>> $foo.bar
>>
>> There is no contract about what class foo is, and how bar is accessed....
>
> [SNAP]
>
> I have an idea: how about generating code also for SMALLTALK?
That would be interesting. :)
>I see
> Velocity's power in it's "mutable types".
Yep. I call it 'Introspective Polymorphism'.
>I know, Jakarta is primary a Java
> project, it's only an idea ...
>
There is nothing that says you couldn't do a Smalltalk Velocity elsewhere.
The more implementations of Velocity, the better.
I *promise* we would link to it :)
> Christian
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Christian Trutz <ch...@smilebase.de>.
[SNIP]
> > to velocity would be required in order to make this actually work. A
> > core that stated immutable types in the context which would allow for
> > real complication with the option to allow mutable types if you wished.
> > Hashtables are convenient and I know people use them but I think that
> > allow mutable types in the context actually promotes bad design.
>
> How's that? When you see
>
> $foo.bar
>
> There is no contract about what class foo is, and how bar is accessed....
[SNAP]
I have an idea: how about generating code also for SMALLTALK? I see
Velocity's power in it's "mutable types". I know, Jakarta is primary a Java
project, it's only an idea ...
Christian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/13/02 12:55 PM, "Jason van Zyl" <jv...@zenplex.com> wrote:
> On Wed, 2002-03-13 at 05:19, Geir Magnusson Jr. wrote:
>
>>
>> I guess the question is - is there any point to doing this? :) It's not
>> clear to me what kind of real performance improvements can be realized by
>> compiling, because once the template is intepreted, it's bytecode, right?
>
> The AST is bytecode, but I believe the compiled form of a template would
> be different in that the reflection would be removed and if types place
> in the context were immutable then I believe the compiler would make
> things faster.
I agree, but this is in fact removing functionality.
>
>> I think the motivation for starting a compiler was when we believed that JSP
>> was incredibly fast and Velocity was slow. Since thing, we have proved to
>> ourselves many times that Velocity is comparable in performance to JSP,
>> which is of course, compiled from generated Java code.
>
> I think velocity is comparable to jakarta implementations of JSP but I'm
> not sure there has been many comparisons with other JSP implementations.
> I am still willing to bet 10 bucks (american bucks ;-)) that the
> compiler would make a significant improvement. But some internal changes
> to velocity would be required in order to make this actually work. A
> core that stated immutable types in the context which would allow for
> real complication with the option to allow mutable types if you wished.
> Hashtables are convenient and I know people use them but I think that
> allow mutable types in the context actually promotes bad design.
How's that? When you see
$foo.bar
There is no contract about what class foo is, and how bar is accessed....
>
>> I would be interested in understanding if there really is potential for
>> improvement doing this, or if we are just making things more complex with no
>> real benefit.
>>
>> In the case above, you took what is now basically
>>
>> for(int j=0; j<numchildren; j++)
>> {
>> getChild(j).render();
>> }
>>
>> And unwound the loop into the two writes
>>
>> I am sure there is performance improvement there and it could significant in
>> such a trivial case (or other optimal situations), but the question is how
>> that improvement scales for real-world templates.
>
> I believe the expansion would be greater than this and the AST wouldn't
> be reference at all in the final compiled version of the template.
>
> I am honestly not going to be tackling any sort of compiler until
> Turbine is finished so I may never be working on a compiler ;-)
Turbine 3 is cool
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Jason van Zyl <jv...@zenplex.com>.
On Wed, 2002-03-13 at 05:19, Geir Magnusson Jr. wrote:
>
> I guess the question is - is there any point to doing this? :) It's not
> clear to me what kind of real performance improvements can be realized by
> compiling, because once the template is intepreted, it's bytecode, right?
The AST is bytecode, but I believe the compiled form of a template would
be different in that the reflection would be removed and if types place
in the context were immutable then I believe the compiler would make
things faster.
> I think the motivation for starting a compiler was when we believed that JSP
> was incredibly fast and Velocity was slow. Since thing, we have proved to
> ourselves many times that Velocity is comparable in performance to JSP,
> which is of course, compiled from generated Java code.
I think velocity is comparable to jakarta implementations of JSP but I'm
not sure there has been many comparisons with other JSP implementations.
I am still willing to bet 10 bucks (american bucks ;-)) that the
compiler would make a significant improvement. But some internal changes
to velocity would be required in order to make this actually work. A
core that stated immutable types in the context which would allow for
real complication with the option to allow mutable types if you wished.
Hashtables are convenient and I know people use them but I think that
allow mutable types in the context actually promotes bad design.
> I would be interested in understanding if there really is potential for
> improvement doing this, or if we are just making things more complex with no
> real benefit.
>
> In the case above, you took what is now basically
>
> for(int j=0; j<numchildren; j++)
> {
> getChild(j).render();
> }
>
> And unwound the loop into the two writes
>
> I am sure there is performance improvement there and it could significant in
> such a trivial case (or other optimal situations), but the question is how
> that improvement scales for real-world templates.
I believe the expansion would be greater than this and the AST wouldn't
be reference at all in the final compiled version of the template.
I am honestly not going to be tackling any sort of compiler until
Turbine is finished so I may never be working on a compiler ;-)
> Geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "He who throws mud only loses ground." - Fat Albert
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 3/13/02 5:11 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>> What is a "real-world" template? 10K, 100K, 1M velocity code?
>
> I have seen some big ones from people doing heavy XML processing.
>
> But a template that does a bit of looping, flow control (#if/#else), etc is
> representative of the common use patterns of VTL (the Velocity Template
> Language)
http://scarab.tigris.org/source/browse/scarab/src/templates/
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/13/02 7:48 AM, "Christian Trutz" <ch...@smilebase.de> wrote:
> Am Mittwoch, 13. März 2002 11:19 schrieben Sie:
>> On 3/13/02 2:26 AM, "Christian Trutz" <ve...@smilebase.de> wrote:
>>> Hello Velocity community,
>>>
[SNIP]
>>>
>>> Is this a good idea???
>>
>> Not sure - I mean, JSP does this :)
>
> JSP, JSP ... ??? ... ah I know, this pre-historical stuff from Sun ;-)
It seems it ain't dead yet :)
>>
>>> Is anybody working on a Velocity template compiler?
>>
>> I guess the question is - is there any point to doing this? :) It's not
>> clear to me what kind of real performance improvements can be realized by
>> compiling, because once the template is intepreted, it's bytecode, right?
>
> OK, the JSP like compilation has perhaps only little improvement, perhaps the
> only improvement in the situation when you must scan/parse the same template
> file many times. Has Velocity a cache-like mechanism for this?
Of course. We may have been born at night, but it wasn't *last* night...
;->
[SNIP]
>>
>> I am sure there is performance improvement there and it could significant
>> in such a trivial case (or other optimal situations), but the question is
>> how that improvement scales for real-world templates.
>
> What is a "real-world" template? 10K, 100K, 1M velocity code?
I have seen some big ones from people doing heavy XML processing.
But a template that does a bit of looping, flow control (#if/#else), etc is
representative of the common use patterns of VTL (the Velocity Template
Language)
>The merge
> process is also dependent from the context (loops with 10 iterations and
> loops with 10^7 iterations ...). I think there are 2 points for improvements:
>
> 1) run the scan/parse process only once and compile the template, this can be
> performant, if you must scan/parse many times the same template ...
We do that.
> 2) merge(Context,Writer) method, JSP-like compiled code is in the O-notation
> the same as walking thru AST nodes ;-) but I think it's a difference in the
> constants ...
So we don't care as long as the constant isn't that huge - which I don't
think it will be.
> I will make some profile experiments with little, medium and large template
> files.
That would be great.
>>
>>> The AST (see JJTree) implemets the visitor pattern and any AST node has a
>>> render method ... why? Is rendering with a visitor not so good?
>>
>> We use the tree for different things, and the render() approach works quite
>> well for us. Visitor is good, and we do use it for things, sometimes...
>
> OK sorry ;-) it was only an academic question ...
No worries... I've used the visitor very effectively in other things liike
this I have done - allowed me to do specialized initializations and such w/o
having to define it in specific node methods...
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Java : the speed of Smalltalk with the simple elegance of C++...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Christian Trutz <ch...@smilebase.de>.
Am Mittwoch, 13. März 2002 11:19 schrieben Sie:
> On 3/13/02 2:26 AM, "Christian Trutz" <ve...@smilebase.de> wrote:
> > Hello Velocity community,
> >
> > I am new to this mailing list, my name is Christian Trutz and I am a
> > graduate student (mathematics) at University Bonn in Germany. Velocity is
> > for me a cool and useful tool and I want to contribute a little.
>
> Great
>
> > In the actual CVS tree there is a incomplete
> > org.apache.velocity.runtime.compile.Compiler class. This class wants to
> > compile a template via BCEL. I think it's better to generate first a java
> > file and then compile this with an usual compiler. What I mean:
> >
> >
> > Velocity file:
> > -----------
> > Hello $foo
> > -----------
> >
> > after "compilation" you get something like this:
> >
> > ----------------------------------------------------------
> > public class CompiledTemplate {
> >
> > public void merge( Context context, Writer writer) {
> >
> > writer.write("Hello ");
> > writer.write( context.get( "foo" ) );
> > }
> > }
> > --------------------------------------------------------
> >
> > Is this a good idea???
>
> Not sure - I mean, JSP does this :)
JSP, JSP ... ??? ... ah I know, this pre-historical stuff from Sun ;-)
>
> > Is anybody working on a Velocity template compiler?
>
> I guess the question is - is there any point to doing this? :) It's not
> clear to me what kind of real performance improvements can be realized by
> compiling, because once the template is intepreted, it's bytecode, right?
OK, the JSP like compilation has perhaps only little improvement, perhaps the
only improvement in the situation when you must scan/parse the same template
file many times. Has Velocity a cache-like mechanism for this?
>
> I think the motivation for starting a compiler was when we believed that
> JSP was incredibly fast and Velocity was slow. Since thing, we have proved
> to ourselves many times that Velocity is comparable in performance to JSP,
> which is of course, compiled from generated Java code.
>
> I would be interested in understanding if there really is potential for
> improvement doing this, or if we are just making things more complex with
> no real benefit.
>
> In the case above, you took what is now basically
>
> for(int j=0; j<numchildren; j++)
> {
> getChild(j).render();
> }
>
> And unwound the loop into the two writes
>
> I am sure there is performance improvement there and it could significant
> in such a trivial case (or other optimal situations), but the question is
> how that improvement scales for real-world templates.
What is a "real-world" template? 10K, 100K, 1M velocity code? The merge
process is also dependent from the context (loops with 10 iterations and
loops with 10^7 iterations ...). I think there are 2 points for improvements:
1) run the scan/parse process only once and compile the template, this can be
performant, if you must scan/parse many times the same template ...
2) merge(Context,Writer) method, JSP-like compiled code is in the O-notation
the same as walking thru AST nodes ;-) but I think it's a difference in the
constants ...
I will make some profile experiments with little, medium and large template
files.
>
> > The AST (see JJTree) implemets the visitor pattern and any AST node has a
> > render method ... why? Is rendering with a visitor not so good?
>
> We use the tree for different things, and the render() approach works quite
> well for us. Visitor is good, and we do use it for things, sometimes...
OK sorry ;-) it was only an academic question ...
Christian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by Attila Szegedi <sz...@freemail.hu>.
----- Original Message -----
From: "Geir Magnusson Jr." <ge...@optonline.net>
To: "Velocity Developer's List" <ve...@jakarta.apache.org>
Sent: 2002. március 13. 11:19
Subject: Re: Velocity Compiler
>
>
> I guess the question is - is there any point to doing this? :) It's not
> clear to me what kind of real performance improvements can be realized by
> compiling, because once the template is intepreted, it's bytecode, right?
>
I don't believe there is. Only the unfolded sequence of AST tree traversal
is the potential target for compilation (since that's what is now
interpreted) and I guess (altough I must admit that I didn't profile) that
the traversal itself (not counting the calls to methods of tree nodes to
render themselves, which are already compiled code) makes for a *very tiny*
slice of rendering time. The time spent on invoking methods and properties
on the data model as well as the char-to-byte conversions on the output are
the likely hotspots, not the AST traversal.
Attila.
>
> Geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "He who throws mud only loses ground." - Fat Albert
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity Compiler
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 3/13/02 2:26 AM, "Christian Trutz" <ve...@smilebase.de> wrote:
> Hello Velocity community,
>
> I am new to this mailing list, my name is Christian Trutz and I am a graduate
> student (mathematics) at University Bonn in Germany. Velocity is for me a
> cool and useful tool and I want to contribute a little.
Great
>
> In the actual CVS tree there is a incomplete
> org.apache.velocity.runtime.compile.Compiler class. This class wants to
> compile a template via BCEL. I think it's better to generate first a java
> file and then compile this with an usual compiler. What I mean:
>
>
> Velocity file:
> -----------
> Hello $foo
> -----------
>
> after "compilation" you get something like this:
>
> ----------------------------------------------------------
> public class CompiledTemplate {
>
> public void merge( Context context, Writer writer) {
>
> writer.write("Hello ");
> writer.write( context.get( "foo" ) );
> }
> }
> --------------------------------------------------------
>
> Is this a good idea???
Not sure - I mean, JSP does this :)
>
> Is anybody working on a Velocity template compiler?
I guess the question is - is there any point to doing this? :) It's not
clear to me what kind of real performance improvements can be realized by
compiling, because once the template is intepreted, it's bytecode, right?
I think the motivation for starting a compiler was when we believed that JSP
was incredibly fast and Velocity was slow. Since thing, we have proved to
ourselves many times that Velocity is comparable in performance to JSP,
which is of course, compiled from generated Java code.
I would be interested in understanding if there really is potential for
improvement doing this, or if we are just making things more complex with no
real benefit.
In the case above, you took what is now basically
for(int j=0; j<numchildren; j++)
{
getChild(j).render();
}
And unwound the loop into the two writes
I am sure there is performance improvement there and it could significant in
such a trivial case (or other optimal situations), but the question is how
that improvement scales for real-world templates.
>
> The AST (see JJTree) implemets the visitor pattern and any AST node has a
> render method ... why? Is rendering with a visitor not so good?
We use the tree for different things, and the render() approach works quite
well for us. Visitor is good, and we do use it for things, sometimes...
Geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"He who throws mud only loses ground." - Fat Albert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>