Re: Flow control by Exception

On Fri, Feb 6, 2009 at 12:52 AM, Bruce Ritchie <[email protected]> wrote:
> Jonathan,
>
>>> If it was static it at the very least wouldn't incur the
>>> fillInStackTrace JVM call which is so painful performance wise - being
>>> static isn't an issue in this case since this exception is never
>>> rethrown as best as I can tell.

Yes, it seems that this instance of LookaheadSuccess could perfectly
well be static. Actually, now that I actually look at this, it seems
quite easy to address. I just tweaked the 2.3 build.xml to make that
variable static. It's just a replace string on the generated
FMParser.java "private final LookaheadSuccess" -> "private static
final LookaheadSuccess".

And, yeah, AFAICS, there is no problem with just reusing the singleton
LookaheadSuccess object. It's really just a dummy object. So
basically:

svn co https://freemarker.svn.sourceforge.net/branches/2.3/freemarker
cd freemarker
ant

should build you a 2.3 freemarker.jar where that object is static.

I also have addressed this in FreeCC. It uses a static variable in that spot.

Thanks for bringing this up.

Regards,

JR

>>
>> Yes, that is probably quite easy to address and I'll have a look at
>> that in FreeCC. But note that any improvements on this will only be
>> for 2.4.x. It may be a while before you can (at least while applying
>> proper caution) standardize on FM 2.4. The best you can do meanwhile,
>> I guess, is to see if you can lessen your use of ?eval.
>>
>
> Yep, I switched to an eval(expressionString) put into the context
> which caches the parsed templates resulting in a noticeable
> improvement in performance.
>
>>>
>>> Is the 2.4 FMParser going to be better about this?
>>
>> I think yes. Most probably... :-)
>
> Understood. fwiw filIInStackTrace is #2 in tick count (behind gc) at
> anywhere between 5 and 10% of cpu time on the azul box I've been
> testing on. Now not all of those exceptions are freemarker but a good
> majority are (well were, I keep finding more things to cache).
>
>>  And actually, aside from
>> this issue, 2.4 really does address a lot of the shortcomings in 2.3.
>> (Annoying issues wrt java nulls, cleaning up scopes and variable
>> declaration, are just a couple of examples...) Most of that stuff has
>> has been done for like a couple of years, but we really just need to
>> get it stabilized and out there. Not a great project management
>> story.... it's mostly my fault I know... :-(
>
> I'm fine with things like this only going into 2.4 ... as long as I
> know they are being looked at :)  We've actually toyed around with the
> idea of rewriting the FreeMarker parser in the past to fix this issue
> among others .. that is, until you started to work on FreeCC. Thanks
> for looking into this!
>
>
> Regards,
>
> Bruce Ritchie
>
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and code to
> build responsive, highly engaging applications that combine the power of local
> resources and data with the reach of the web. Download the Adobe AIR SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com