Limit on # of nodesWe are

[Som]

We are implementing a treeview where the # of nodes could exceed 5000 nodes. We are using ServerSideCallBack to populate the children nodes and have noticed that the treeview control stops responding if the # of nodes exceeds 800-900.  After a while an error  message pops up "A script on this page is causing internet explorer to run slowly. If it continues to run, your computer may become unresponsive. Do you want to abort the script". If I select "No", sometimes (based on the # of nodes)  it loads the children and at other times it just freezes.

What would suggest in this scenario ? Is there a way that we could load the children in smaller chunks ? Let us know.

[Atanas Korchev]

Hi Som,

This may occur if you are testing the web page in debug mode (<compilation debug="true"> in the web.config). In that case the MS Ajax library runs in debug mode which slows things down a bit because of various asserts and verifications. You can try configuring your ScriptManager to always use the release scripts.

ASPX:

<asp:ScriptManager ScriptMode="Release" />

Codebehind:

ScriptManager1.ScriptMode = ScriptMode.Release;

I hope this helps,
Albert
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Som]

thanks Albert for your suggestion. It did help with the performance but we still have issues when the # of nodes start getting close to or exceeding 500. In order to isolate the issue, we used ServerSide call back mode and that works very well. The problem is when we are using ServerSideCallBack. Any ideas??

[Atanas Korchev]

Hello Som,

Is the performance issue reproducible on our online example? I tried expanding ~30 nodes but performance didn't degrade noticeably.

At the time being RadTreeView logs all nodes created on demand so they are later available on the server side. There is a property to control that behavior - "PersistLoadOnDemandNodes". However it is not implemented for expandmode = serversidecallback, it works only for web-service load on demand. Once we implement it nodes created on demand won't be logged on the client-side (which could potentially slow things down). A "fake" node would be supplied during the NodeExpand event instead of the "real" one. This would be actually the same load on demand implementation used in "Classic" RadTreeView.

Having that in mind you can try with ExpandMode = WebService and PersistLoadOnDemandNodes = false. this setup should not get slower

Regards,
Atanas Korchev,
the Telerik dev team

Instantly find answers to your questions at the new Telerik Support Center

[Ian]

I'm having the exact same problem.

I'm using ServerSideCallBack and anytime the number of nodes returned exceeds a couple hundred, IE basically locks up. It works fine in Firefox and Safari, but IE can't handle it.

I'm not in Debug mode. I'm using RadScriptManager and RadAjaxPanel.

The fact that it is blazing fast in Firefox and Safari and only bogs down in IE proves it's not a server-side error.

There is some malfeasance on the client-side in Internet Explorer when using ServerSideCallback in Prometheus Treeview. It's funny that works great in non-Microsoft browers, but not really since it needs to work in IE.

[John Billiris (JSBBS)]

I am experiencing the same client-side performance issues.

IE7 is EXTREMELY slow to respond to node expansion - whereas Firefox is responding beautifully - when the number of nodes exceeds 400.

To the guys at Telerik, please check the differences that you have coded for IE -v- Firefox in your javascript resources. If need be, please escalate to Microsoft.

[John Billiris (JSBBS)]

I certainly hope that this Telerik blog is related !!!

Internet Explorer JavaScript Performance Tip

[Paul]

Hi jsbbs,

Yes, this blog post is related to the problem. The good news is this fix will be included in the next SP due to be released till the end of the week.

Best wishes,
Paul
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Mikael]

Another possible performance improvement might be to look at how the javascript code walks up the DOM-tree in different occasions.

A few months ago, I was trying to figure out why the RadControls were performing worse when used in a WSS-page compared to a simple ASPX-page. (Note that this was before Promotheus, so it might not be applicable anymore). I noticed that, many times, the script code would traverse from an HTML element up the DOM-tree, looking for a specific tag. If it didn't find the tag, it would end up at the root of the DOM-tree.
This might explain the performance difference. WSS-pages are extremely "deep" - a RadControls used in a WSS webpart would be something like 20 levels down from the root. Compared to a ASPX-page, where the RadControl would sit more or less directly under the root, the time to traverse up the DOM-tree would of course be might higher.
Sorry for being so vague about the details, but I can't remember the piece of code that was doing this, but it was either a RadTreeView or a RadGrid.

So, if this is still applicable in Promotheus, you might want to consider having a more clever exit criteria for traversing, than walking all the way to the top of the DOM. For instance, if the code has reached the root of the RadControl's DOM-subtree  itself, it could stop traversing, since the tag it was looking for must reside in the subtree.

Again, sorry for the vague information, I haven't looked at this problem for a while.

Thanks for a great product and support!
/Fredrik

[John Billiris (JSBBS)]

Paul,

Can you confirm which version of Telerik.Web.UI.dll contains the fix?

I've now got 2008.2.826.35 and I'm still encountering the poor performance !!

[Atanas Korchev]

Hi,

We are currently working on optimizing RadTreeView performance when loading on demand lots of nodes. We are currently testing with 1000 nodes at a time and on most browsers it takes less than 1 sec.

The first performance optimization described in my blog post is included in the SP1 release (2008.2.826.35). However it affects mostly the initialization time rather than load on demand (despite it will improve things a bit).

Anyway have in mind that loading huge number of nodes (above 2-3000 at a time) will still not perform good as browser tend to choke on that much HTML (IE for example). By "choke" I mean that the browser fails to respond on user interaction properly (DOM events fire slower when dealing with lots of HTML).

Having said that I will be glad if you guys sends us some of your pages which have performance issues so we can test how they perform with the current build.

Regards,
Atanas Korchev,
the Telerik dev team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[Stefan]

Hi Atanas,

I've got the same problem, that I have to load 500 nodes in one level on demand after a server side call back and in IE8 it takes "ages" while it's really quick in Firefox. The referenced version of the telerik lib we are using is 2009.1.311.35, so this changes which you were talking about should be already included. But also you mentioned "However it affects mostly the initialization time rather than load on demand". Do you still work on this issue? How is the state of affairs? When we can anticipate with a solution to this problem? Could you maybe suggest any quick fixes right now?

Thanks for your help, Stefan

[Atanas Korchev]

Hi Stefan,

I've tested this case IE8 loaded 500 nodes in 1800ms. Firefox did it in ~900ms which is expected as Firefox has a lot better JavaScript engine than IE. I've tested using the current official release 2009.1.402 which should behave in similar manner as 2009.1.311. What might be different in your case? How much time does it take to load those nodes? You can also try the sample web site I've attached.

Regards,

Atanas Korchev,

the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Stefan]

Hi Atanas,

 

I've tested your example on my machine and as it basically does the same like the one I made for testing it also performs the same. On my machine (some core 2 duo with 2.4 Ghz and 4 gb) I get around 2400ms on IE8 vs. 650 in Firefox 3 which is almost four times as slow. So that's the example case.

 

Now when we come to the real world my tree lives in a control almost all alone (sharing it with two tiny image buttons and a drop down list with currently 2 entries) which itself is resided (all alone) in an update panel which lives in a hirarchy of a bunch of rad layouting controls (in that order going upwards the hierarchy: rad dock, rad dock zone, rad dock layout, rad pane, rad splitter, rad pane, rad splitter) in our main page having two more master pages on top. The server side processing is pretty quick. I hooked up your java script to my tree and the results are around 5100 for IE8 vs. 1100 for Firefox3. Just for the first time I start the application in IE it even takes 9000 - 13000, after when I just restart the app in new sessions it constantly takes around 5100 ms. For Firefox I didn't notice any difference.

Anyway, I think our customers will have rather slower machines than mine, so I guess it will be worse for them. Is it so slow in IE because of the deep control hierarchy? Is there no way of some Java Script hack not starting in the DOM root but doing some optimization. Or is it simply not possible to make it quicker in IE? Actually our app only needs to support IE, so there's no need for compatibility and we could even use some IE specific functionality.

[Atanas Korchev]

Hi Stefan,

There are two things you can do to improve performance:

1. User web service load on demand
2. Set the PersistLoadOnDemandNodes property to false if you don't need need the nodes loaded on demand back on the server side.

Other that that there is no way to improve performance in Internet Explorer.

Regards,

Atanas Korchev,

the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Stefan]

Hi Atanas,

Btw. thanks for your quick answers :-)

1. Does that relly help improving client side performance? Any ideas how much we could gain?

 

2. Tried that yesterday, unfortunately we are using the tri state check box feature and it seems to break (for example the ClearCheckedNodes() method as I just posted in another thread) once I switch off PersistLoadOnDemandNodes. Or is it that this will work again, once we are not using the server side load on demand anymore?

Greetings, Stefan

[Atanas Korchev]

Hello Stefan,

You can check this online demo and see for your self (it has persistloadondemand nodes set to false however).

Tristate checkboxes will probably not work as  but should not fail either. Perhaps I need more info about all your requirements - checkboxes, load on demand etc. Also how and when does the ClearCheckedNodes method fail? What do I need to do in order to reproduce this problem in my sample page? There is one more thing - make sure the debug attribute of the <compilation /> tag in web.config is set to false. This would improve performance.

Of course you can also consider reducing the number of nodes loaded simultaneously. I am not sure how easy it would be for the end user to locate the required node when there are thousands of nodes in the treeview unless there is some kind of search or filter.

Regards,

Atanas Korchev,

the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Stefan]

Somewhere else in the forum I read that you can also set the ScriptMode="Release" in the ScriptManager and it should have the same effect as disabling the debug mode (at least on the client side), so I did this, nevertheless once I tried disabling debug mode but it didn't really help.

The online demo seems to manage pretty quick, so I guess I'll try the web service approach.

Requirements are that we need to display different trees (only on at a time) with approximately 5000-10000 nodes, so we use load on demand, which for small numbers of fetched nodes works fine. Nodes can be checked, in upper layers tri state is displayed. The check state is only processed once the user clicked a button. So the only tree event we need is the node expand for fetching new nodes. Sometimes the tree is synchronized with other ways of selecting "entities" somewhere else in the app, so if there nothing is selected we use the ClearCheckedNodes() method which just runs and runs and runs, I didn't wait and didn't check what happens inside, just noticed that it doesnt come back for too long time, after I switched on persistloadondemand it worked fine again.

That's our tree:

 

<telerik:RadTreeView

 

 

ID="t"

 

 

runat="server"

 

 

CheckBoxes="true"

 

 

TriStateCheckBoxes="true"

 

 

CheckChildNodes="true"

 

 

OnNodeExpand="OnT_NodeExpand"

 

 

OnClientNodeChecked="ClientNodeChecked"

 

 

PersistLoadOnDemandNodes="false" />

 

I hooked up some Java Script for easily selecting several nodes with "Alt+Click", but I don't think that doesn't change a lot, do you?

Indeed you are right, 500 nodes are not really usable anymore, and I guess that wont be the standard case, but after the client decides and it actually may be like this.

[Atanas Korchev]

Hi Stefan,

The main delay comes from PersistChildNodes=true. Each node loaded on demand is serialized in JSON in order to be recreated back on the server side. Then it comes the three-state checkbox rendering - since is is not the default checkbox, which is rendered natively by the browser, it consumes some time to render. Finally you can set the ShowLineImages property to false which will improve slighlty the rendering speed. The line images are rendered as background of some elements which takes some time in internet explorer.

The problem with CheckChildNodes sounds as a bug and I would really like to reproduce it and fix it. Unfortunately I have failed to reproduce it locally using my test project. No matter how many nodes I checked the ClearCheckedNodes method always succeeded in no time.

Regards,

Atanas Korchev,

the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

[Stefan]

Hi Atanas, I hHave to work on some other stuff for the moment, as soon as I come back to this for sure I will try again the persistloadondemand thing and I can check quickly if I find the reason for that issue. I keep you informed, thanks for the moment for all the tips. Greetings Stefan

[Stefan]

I tried implementing the asmx web service on demand loading. Unfortunately, when I click the "+" icon, I always get a popup asking me to authenticate myself with a user name and password which I don't know and after 3 tries it says "Authentication failed". We're using windows authentication. Even more strange I tried to reproduce it in a sample project and there it perfectly works without any questions. When reproducing I used the same settings in IIS, the project, I copied the web.config and I also copied the web service. Did anyone ever had this problem or has an idea what else I might try?

[Gani]

Hi

Question about JsonSerialization.
I saw that for the RadTreeVieNode API: node.set_checked(...); the code is:

set_checked:function(_b4,e){
 
this._check(_b4,e);
if(this.get_treeView()){
this.get_treeView()._updateCheckedState();
}
}

 
_updateCheckedState:function(){
this._checkedNodesJson=Sys.Serialization.JavaScriptSerializer.serialize(this._clientState.checkedNodes); // line XXX
this.updateClientState();
}

Now profiling the loop

var cnt = treeNodes.get_count();
for(var i = 0; i < cnt; i++) {
var node = treeNodes.getNode(i);
if (node.get_checked() != checkOrUncheck) {
node.set_checked(checkOrUncheck);
}

I see that > 95% of time we sit in _serializeWithBuilder(...) function. It's called from the line XXX.
Now, I do not need to have this. Since all the operations with RadTreeView i do on client side using client API.
There should be a possibility to disable Jsonization of nodes in the RadTree so I ll get much more performant API.

Pls assist.

Thx
Gani

 

 

 

 

[Sundaresan]

We are implementing a treeview where the # of nodes could exceed 1500 nodes. We are using ServerSideCallBack to populate the children nodes and have noticed that the treeview control stops responding if the # of nodes exceeds 800-900. when we add node and edit not that time its not working in Chrome and IE. Its working in Firefox. Please give the solution for me.