You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Will Glass-Husain <wg...@forio.com> on 2005/01/24 08:42:21 UTC
decimal patch to velocity (performance)
Hi,
Well, after doing a miscellany of patches in the last few weeks I'm tackling
the decimal number patch. (Bugzilla #25874) We've discussed this endlessly
in the past. I've been using this in production code for almost a year.
The remaining issue (raised by committer dlr) is that of performance.
I wrote some simple test code, and discovered there does appear to be a
performance drag with the number patch. With caching turned off, there is
no significant difference. With caching on, merging templates with the
number patch is about 20-25% slower.
I'm really not sure why. Interestingly, the template doesn't matter - the
time is almost the same for a integer-math heavy template or an empty
template.
Methodology. I merged a template 1000 times (loaded from the
ClasspathResourceLoader). Results for Velocity 1.4 and SVN head were almost
identical. Adding the number patch raised the time to do the merging from
488 ms to 604 ms. I ran this a number of times, the timing was pretty
consistent.
Before delving further into profiling, I'd be interested in comments. Is
this significant?
Best, WILL
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: decimal patch to velocity (performance)
Posted by Ilkka Priha <im...@surfeu.fi>.
Hello,
JProbe provides a freeware version without memory debugging support, but with
full method profiling. Easy to use but requires renewal of the license every
fifth month.
http://www.quest.com/jprobe/
-- Ilkka
Will Glass-Husain wrote:
> Hi,
>
> Thanks for the feedback. I've been looking for free profiling tools -
> appreciate the recommendation.
>
> Incidentally, I think switches to turn functionality on and off are
> generally a bad idea. (which was the consensus at the time).
> Especially something which should be a transparent upgrade. Besides,
> it's not clear how to do this here - it's not a single block of code but
> rather new items interwoven throughout Parser.java.
>
> I'll work on profiling. I'd really like to make this work - it's an
> important patch to a significant group of users.
>
> WILL
>
> ----- Original Message ----- From: "Henning P. Schmiedehausen"
> <hp...@intermeta.de>
> Newsgroups: hometree.jakarta.velocity.dev
> To: <ve...@jakarta.apache.org>
> Sent: Tuesday, January 25, 2005 1:49 AM
> Subject: Re: decimal patch to velocity (performance)
>
>
>> "Will Glass-Husain" <wg...@forio.com> writes:
>>
>>> I wrote some simple test code, and discovered there does appear to be a
>>> performance drag with the number patch. With caching turned off,
>>> there is
>>> no significant difference. With caching on, merging templates with the
>>> number patch is about 20-25% slower.
>>
>>
>> I think, that 20-25% are a real problem.
>>
>> Did you try profiling?
>>
>> I haven't tried it yet, but a quick google showed up
>> http://www.eclipse.org/hyades/ which looks like a cool "much more than
>> profiling" framework for Eclipse.
>>
>>> I'm really not sure why. Interestingly, the template doesn't matter
>>> - the
>>> time is almost the same for a integer-math heavy template or an empty
>>> template.
>>
>>
>> This points to a general problem with the patch. Personally, I'd
>> rather drop the decimal patch than getting a 25% performance penalty
>> for something that is not really needed in the templating language.
>>
>> BTW: Wasn't there talk about getting a global switch to turn "the
>> decimal patch" off? What is the impact if the patch is merged but
>> turned off?
>>
>> Regards
>> Henning
>>
>> --
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
>> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>>
>> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for
>> hire
>> Linux, Java, perl, Solaris -- Consulting, Training, Development
>>
>> What is more important to you...
>> [ ] Product Security
>> or [ ] Quality of Sales and Marketing Support
>> -- actual question from a Microsoft customer survey
>>
>> ---------------------------------------------------------------------
>> 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: decimal patch to velocity (performance)
Posted by Will Glass-Husain <wg...@forio.com>.
Hi,
Thanks for the feedback. I've been looking for free profiling tools -
appreciate the recommendation.
Incidentally, I think switches to turn functionality on and off are
generally a bad idea. (which was the consensus at the time). Especially
something which should be a transparent upgrade. Besides, it's not clear
how to do this here - it's not a single block of code but rather new items
interwoven throughout Parser.java.
I'll work on profiling. I'd really like to make this work - it's an
important patch to a significant group of users.
WILL
----- Original Message -----
From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
Newsgroups: hometree.jakarta.velocity.dev
To: <ve...@jakarta.apache.org>
Sent: Tuesday, January 25, 2005 1:49 AM
Subject: Re: decimal patch to velocity (performance)
> "Will Glass-Husain" <wg...@forio.com> writes:
>
>>I wrote some simple test code, and discovered there does appear to be a
>>performance drag with the number patch. With caching turned off, there is
>>no significant difference. With caching on, merging templates with the
>>number patch is about 20-25% slower.
>
> I think, that 20-25% are a real problem.
>
> Did you try profiling?
>
> I haven't tried it yet, but a quick google showed up
> http://www.eclipse.org/hyades/ which looks like a cool "much more than
> profiling" framework for Eclipse.
>
>>I'm really not sure why. Interestingly, the template doesn't matter - the
>>time is almost the same for a integer-math heavy template or an empty
>>template.
>
> This points to a general problem with the patch. Personally, I'd
> rather drop the decimal patch than getting a 25% performance penalty
> for something that is not really needed in the templating language.
>
> BTW: Wasn't there talk about getting a global switch to turn "the
> decimal patch" off? What is the impact if the patch is merged but
> turned off?
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
> Linux, Java, perl, Solaris -- Consulting, Training, Development
>
> What is more important to you...
> [ ] Product Security
> or [ ] Quality of Sales and Marketing Support
> -- actual question from a Microsoft customer survey
>
> ---------------------------------------------------------------------
> 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: decimal patch to velocity (performance)
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Will Glass-Husain" <wg...@forio.com> writes:
>I wrote some simple test code, and discovered there does appear to be a
>performance drag with the number patch. With caching turned off, there is
>no significant difference. With caching on, merging templates with the
>number patch is about 20-25% slower.
I think, that 20-25% are a real problem.
Did you try profiling?
I haven't tried it yet, but a quick google showed up
http://www.eclipse.org/hyades/ which looks like a cool "much more than
profiling" framework for Eclipse.
>I'm really not sure why. Interestingly, the template doesn't matter - the
>time is almost the same for a integer-math heavy template or an empty
>template.
This points to a general problem with the patch. Personally, I'd
rather drop the decimal patch than getting a 25% performance penalty
for something that is not really needed in the templating language.
BTW: Wasn't there talk about getting a global switch to turn "the
decimal patch" off? What is the impact if the patch is merged but
turned off?
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
What is more important to you...
[ ] Product Security
or [ ] Quality of Sales and Marketing Support
-- actual question from a Microsoft customer survey
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: decimal patch to velocity (performance)
Posted by Ilkka Priha <im...@surfeu.fi>.
Hello,
As a heavy user of Velocity templates in many performance critical apps, I'd say
20 - 25 % is significant as you can do quite well without decimals by performing
maths in tools, which was this original idea and always faster than in
templates. 2 - 2.5 % would be acceptable.
-- Ilkka
Will Glass-Husain wrote:
> Hi,
>
> Well, after doing a miscellany of patches in the last few weeks I'm
> tackling the decimal number patch. (Bugzilla #25874) We've discussed
> this endlessly in the past. I've been using this in production code for
> almost a year. The remaining issue (raised by committer dlr) is that of
> performance.
>
> I wrote some simple test code, and discovered there does appear to be a
> performance drag with the number patch. With caching turned off, there
> is no significant difference. With caching on, merging templates with
> the number patch is about 20-25% slower.
>
> I'm really not sure why. Interestingly, the template doesn't matter -
> the time is almost the same for a integer-math heavy template or an
> empty template.
>
> Methodology. I merged a template 1000 times (loaded from the
> ClasspathResourceLoader). Results for Velocity 1.4 and SVN head were
> almost identical. Adding the number patch raised the time to do the
> merging from 488 ms to 604 ms. I ran this a number of times, the timing
> was pretty consistent.
>
> Before delving further into profiling, I'd be interested in comments.
> Is this significant?
>
> Best, WILL
>
> ---------------------------------------------------------------------
> 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