you watching..or what?? couple of weeks and we'll be catching some games on
the new f'in couch!!
----- Original Message -----
From: "cmead" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 04, 2000 5:19 PM
Subject: Re: quick note on recent changes
> go Domi hes the best : P
> ----- Original Message -----
> From: Geir Magnusson Jr. <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, December 04, 2000 8:32 PM
> Subject: Re: quick note on recent changes
>
>
> > Jose Alberto Fernandez wrote:
> > >
> > > I just tried the new version on my test template:
> > > The execution whent from 9sec,824msec to 17sec,515msec.
> > > This is way, way, way over 7%.
> >
> > That *is* way, way over 7%. I was testing against simple servlets, so
> > things must be worse than I feared, or something is strange your way.
> > I would like to find out, so if you are willing to respond with some
> > information, we can get this sorted out. I am a little surprised by
> > these numbers, as I wasn't seeing any problems in the timing of the
> > testbed, which exercises a large range of VTL elements. It actually got
> > a touch faster on my machine. :)
> >
> > There may be an issue with VMs, but I would be surprised as not much
> > really changed for VMs. If you want, I am happy to look at what you are
> > doing to see if we can straighten this out.
> >
> > > As I mentioned on a previous message, I am using Velocity
> > > for XML-XML transformations which means that I am doing a heavy
> > > use of macros. But not much use of #foreach or other directives.
> >
> > Hm.
> >
> > > Additionally my template is using property notation instead of
> > > method notation when passing stuff around.
> > >
> > > To give you an idea of the size of what I am doing, the input is
> > > a 2.8Mb XML file, and the output is 11.8Mb. So there is alot of work
> > > that needs to be done.
> >
> > That's a lot. If you send me an example of what you are doing, something
> > that will be easy for me to see the performance difference, I will be
> > happy to get right on it.
> >
> > geir
> >
> >
> > >
> > > > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> > > >
> > > > Tonight I commited a wide ranging set of changes to address a
> > > > few issues
> > > > that we have been discussing for a while. I want to give everyone a
> > > > heads-up because there is a fair chance I broke something :) (I
don't
> > > > really believe that, of course...)
> > > >
> > > > Visible and Trivial Changes
> > > > ---------------------------
> > > > 1) version of the jar is 0.71 - so velocity-0.71.jar - because the
> > > > changes are deep enough that they aren't simple bugfixes, but rather
a
> > > > re-working of something critical. So if there are problems,
> > > > we know if
> > > > the user says '0.71' that they have the new introspection stuff.
> > > >
> > > > 2) Speed : alas, we took a small speed hit, I estimate about 6%-7%
or
> > > > so. Not big, but not small either. The upshot is that all
> > > > introspection is done at 'run time' rather than init time.
> > > >
> > > > 3) #foreach will restore the pre-loop value of the loop reference.
If
> > > > you want to grab the last element in the loop, do it explicitly.
> > > >
> > > > #set $flargh = "hi"
> > > > #foreach($flargh in $array)
> > > > #end
> > > > $flargh
> > > >
> > > > will output
> > > >
> > > > hi
> > > >
> > > >
> > > > Characteristic Problems Addressed
> > > > ---------------------------------
> > > > There were a few problems that you might have run across, or not.
They
> > > > all were basically related to introspection. They were
> > > > subtle but could
> > > > be deadly :
> > > >
> > > > 1) the #set would invoke the RHS several times, which was
> > > > problematic if
> > > > the invocation of the RHS changed the state of something.
> > > >
> > > > 2) references would invoke their 'referands' more than once.
> > > >
> > > > 3) the introspection information would be 'locked in' at
> > > > init() time in
> > > > some cases, resulting in limitations on app behavior. For example,
if
> > > > you tried something like :
> > > >
> > > > <get template with a #foreach($a in $datalist)>
> > > >
> > > > <create a vector 'v' with some elements>
> > > > context.put("datalist", v);
> > > > template.merge(context, writer);
> > > >
> > > > <create a Object [] 'objarr' with some elements>
> > > > context.put("datalist", objarr);
> > > > template.merge( context, writer);
> > > >
> > > > resulted in ugliness (usually threw an exception, I think.)
> > > >
> > > > Why do we care? Well, suppose in a multithreaded environment, say a
> > > > servlet engine, it's possible that many servlets will be
> > > > using the same
> > > > cached template, and we can't impose the requirement that
> > > > they all have
> > > > data in the Context with the same 'shape'. Well, we could, but we
> > > > won't. :)
> > > >
> > > > For more info, see the new JUnit test, ContextSafetyTestCase.
> > > >
> > > > There was plenty of other stuff, but I think that's the basics...
> > > >
> > > > geir
> > > >
> > > > --
> > > > Geir Magnusson Jr. [EMAIL PROTECTED]
> > > > Dakota tribal wisdom: "when you discover you are riding a dead
horse,
> > > > the best strategy is to dismount."
> > > >
> >
> > --
> > Geir Magnusson Jr. [EMAIL PROTECTED]
> > Dakota tribal wisdom: "when you discover you are riding a dead horse,
> > the best strategy is to dismount."
>
>
