Performance ... again

[Mike Baroukh <mb...@cardiweb.com>]

Hi.

I need some advice about performance on an application I'm actually writing.
Some days ago I saw a lot of message speaking about performance.
I understood there is problems with :
- freemarker :

    by adding a freemarker.properties file in classpath with something like
    template_update_delay=3600
    freemarker should cache compiled template for one hour.

    But: I saw a message saying that freemarker doesn't cache template 
that come from classpath.
    I tried but, for me, all template are correctly cached. No 
re-compilation occur.
    Do I missed something ? Is there any other performance issue with it ?

- ognl :

    ognl seems to be slow when there is method call.
   
    I made some tests and yes, it's very slow : on my PIV, 3Ghz, each 
call to getText() take approximatively 200ms.
    Of course, i18n reloading is disabled.
    Is there a plan to fix this in 2.0.x branch ? At least, is there a 
way to fix it ?
    I saw that there is a proposal to make switchable expression 
languages (http://jira.opensymphony.com/browse/XW-461) but there is no 
schedule.
   
    without method calls, ognl is "relatively" fast but not so much : 
between 0 to 15ms by statement.


I'm using 2.0.1.
I tried to upgrade to 2.0.5, but I stopped because it don't work out of 
the box. I'll try later ...
So do you think I'd should for now
- try again 2.0.5 because there is fixes in it ?
- remove all getText() called in jsps ? (not always possible ...)
- no solutin before 2.1.x ?
- anything else ?
- help you ? how ?

Thanks for your time.  

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Performance ... again

[Mike Baroukh <mb...@cardiweb.com>]

 >Are you absolutely sure that all i18n reloading is off?  There are a 
couple of ways to enable it, not just one.

Yes, I'm sure because changing the entry in the property file doesn't 
change the label printed.


Also, not all take the same time.
Some take 1ms, most 50~100 and a few take up to 350ms.

for 350ms, the statement is
%{getText('libelle.detail.du', {getText('object.type')})}
this is because I have standard entries and I only have to change the 
value of 'object.type' to  personnalize it.
in the properties file I have
libelle.detail.du=D\u00e9tails du {0}

there is no way to do it directly in properties files.
Sure something like
libelle.detail.du=D\u00e9tails du {object.type}
would be fine but it would need a custom resourcebundle.



Thanks.

Mike


David H. DeWolf a �crit :
>
>
> Mike Baroukh wrote:
>
>>      I made some tests and yes, it's very slow : on my PIV, 3Ghz, 
>> each call to getText() take approximatively 200ms.
>
> These are similar to the initial numbers that I saw, however, after 
> tweaking my configuration, my getText() invocations are much faster 
> than that - consistently between 5-15 ms.  Are you absolutely sure 
> that all i18n reloading is off?  There are a couple of ways to enable 
> it, not just one.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>


-- 

Mike Baroukh

---
Cardiweb  - 31 Rue de Mogador Paris IXeme
06 63 57 27 22 - 01 53 21 82 63 - Jabber: mbaroukh@jabber.org
http://www.cardiweb.com
---

Re: Performance ... again

["David H. DeWolf" <dd...@apache.org>]

Mike Baroukh wrote:

>      I made some tests and yes, it's very slow : on my PIV, 3Ghz, each 
> call to getText() take approximatively 200ms.

These are similar to the initial numbers that I saw, however, after 
tweaking my configuration, my getText() invocations are much faster than 
that - consistently between 5-15 ms.  Are you absolutely sure that all 
i18n reloading is off?  There are a couple of ways to enable it, not 
just one.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org