[
https://issues.apache.org/jira/browse/WICKET-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867727#action_12867727
]
Russell Morrisey edited comment on WICKET-1707 at 5/14/10 9:05 PM:
-------------------------------------------------------------------
Matej,
I'm experiencing this performance hit in IE8 (using IE7 standards mode). The
poor performance happens when the markup for the component to be replaced is
large and complex. IE hangs in the case where:
(tn != 'TBODY' && tn != 'TR' && tn != "TD" && tn != "THEAD" && tn != "TFOOT" &&
tn != "TH")
...on the first line:
tempDiv.innerHTML = '<table style="display:none">' + markIframe(text) +
'</table>';
The innerHTML assignment, not the markIframe(...) call is what causes the
slowdown. In my particular use case, it makes the inmethod datagrid take 6
seconds to render when repainted by an ajax request (it renders instantly when
javascript is disabled, when I change the datagrid page using the ajax fallback
link behavior). I verified using the IE8 developer tools debugger that this
operation is the source of the slowdown.
(Edit: I thought at first that the regex usage in markIframe was responsible. I
tried jQuery: $(element).replaceWith(text), but this didn't result in any
noticeable performance improvement. Had trouble coming up with a faster
solution, even if I cut out the hacks in the code for dealing with script tags
and iframes.)
was (Author: rmorrisey):
Matej,
I'm experiencing this performance hit in IE8 (using IE7 standards mode). The
poor performance happens when the markup for the component to be replaced is
large and complex. IE hangs in the case where:
(tn != 'TBODY' && tn != 'TR' && tn != "TD" && tn != "THEAD" && tn != "TFOOT" &&
tn != "TH")
...on the first line:
tempDiv.innerHTML = '<table style="display:none">' + markIframe(text) +
'</table>';
The innerHTML assignment, not the markIframe(...) call is what causes the
slowdown. In my particular use case, it makes the inmethod datagrid take 6
seconds to render when repainted by an ajax request (it renders instantly when
javascript is disabled, when I change the datagrid page using the ajax fallback
link behavior). I verified using the IE8 developer tools debugger that this
operation is the source of the slowdown.
> Wicket.replaceOuterHtmlIE() (wicket-ajax.js) has very low performance.
> ----------------------------------------------------------------------
>
> Key: WICKET-1707
> URL: https://issues.apache.org/jira/browse/WICKET-1707
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Environment: IE 7.0
> Reporter: Bartosz Owczarek
> Assignee: Matej Knopp
>
> Hi.
> Firstly I'd like to say that I'm using wicket framework in my company in
> 'e-commerce' system for Business Users. Its main functionality is ordering
> items available in stores by business users. Items are displayed in a
> customized table (we're using DataView component for it). This table is a
> little bit complicated from DOM point of view. Some columns contain images,
> input components, and different css styles for each row or even column (that
> are added dynamically in javacode using AttributeModifier). There's about 22
> columns in table.
> Moreover table is paginable and number of items per page can be change by
> filter on the web page (default is 50). Paging table is done by our
> customized paging navigator that uses AjaxEventBeahvior. In other words table
> is refreshed using build-in ajax provided with wicket. Whati is more only
> <tbody> tag with its content is refreshed by ajax request (not whole <table>).
> After implementation I've done some testing so here are results...
> Table is refreshed very quickly in FireFox 3 by wicket-ajax.js after
> receiving response but there is a huge performance bottleneck with refreshing
> it in IE 7.0.I profiled whole wicket-ajax.js in order to find this
> bottleneck. It appears that replacing outer html in IE takes about 4 seconds
> (druing which IE freezes). It's not acceptable. I found that
> Wicket.replaceOuterHtmlIE() method takes around 3.7seconds! That's when only
> 50 items in table are displayed!. If we change items per page to greater
> number then it takes much more time. When I commented body of this function,
> IE doesn't freeze and performance is very good, but content that comes with
> ajax response is not refreshed in browser, which is obvious.
> Then I tried to use jQuery(..).replaceWith() function in
> Wicket.replaceOuterHtmlIE() whereas rest of its body was commented. It is
> faster than default Wicket.replaceOuterHtmlIE() implementation. It takes
> about 1.7 second to render response in browser but of course it doesn't do
> all things as default Wicket.replaceOuterHtmlIE() implementation does (i.e.
> default implementation runs embedded javascripts in <script> tags etc.).
> So there is a question...
> Is it possible to improve wciket-ajax.js to get better performance with
> replacing html in ajax request in IE or have you any idea how to improve
> speed in replacing html of such table content in IE ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
