Just a bit more information. I have profiled (using firebug) the action
(always the same action with the same content) with and without the
<s:tabbedpanel> tag and here are the results:
Without:
---
1727.355ms
1424.947ms
1748.429ms
1523.518ms
1539.649ms
1606.369ms
1657.058ms
1599.767ms
1632.157ms
1564.907ms
With:
----
2294.719ms
2513.386ms
3398.823ms
4414.39ms
5716.896ms
7383.391ms
10188.268ms
12604.345ms
15876.5ms
20576.395ms
As you can see, executing the action with the tag multiplies by 10 the
response time!, while when not using the tag, response times are more or
less equilibrated.
Jeromy Evans escribió:
Pablo Vázquez Blázquez wrote:
Any idea about why am I getting increasing response times each time I
access to the page?
I have already a great response time the first time I access to the
page (which is also a problem), but my main problem is that after 6
or 7 accesses it in unmanageable...
Thanks!
I don't recall the 0.4 dojo tabbed panel being particularly slow to
render, other than the extreme initial page load while Dojo makes too
many http requests.
I can't think of any reason why it would get slower after a genuine
page reload with the same content (if it's reloading via ajax though,
then there's a good reason). The reload problem is not evident in the
showcase: it's consistently unbearably slow for each reload at
planetstruts.
Dojo parses your html for widget markup, so it there's a lot of
mark-up inside the tabs it's going to be slooowww (such as tables).
Whenever I had a dojo problem I created a simplified page of html with
just the one widget on it to isolate the cause. You're putting
yourself through unnecessary torture by not using a newer client-side
library though.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
