I profiled our app and found telerik controls took a lot of time in RegisterScriptDescriptors.
Also RadEditor spends much time in FillDefaultDialogDifinitions in EmbededResoureceLocator.GetString()
Is it ok? and is it any way to optimize it?
Also RadEditor spends much time in FillDefaultDialogDifinitions in EmbededResoureceLocator.GetString()
Is it ok? and is it any way to optimize it?
5 Answers, 1 is accepted
0
ManniAT
Top achievements
Rank 2
Rank 2
answered on 08 May 2009, 11:29 AM
Hi Sergey,
you question "Is it ok?" is the general question in performance tuning.
There only one instance who can answer this question: your customer :)
If he opens a page with hundreds of controls and it takes (just a number) 2 seconds - is this to long?
It depends on the situation - if this form opens after every letter he types in a textbox - NO much to slow.
If it is the "entry screen" (or "order confirmation screen") visited 2 times a day it would not be a problem.
One problem is the client hardware - and especially the browser (it's script engine).
The next thing - you said "I profiled your app" - which app? The samples I guess.
The samples (most of the time) are "untypical" - they are intended to show you the possibilities of the controls.
And except some sections (about data / performance) they are "optimized for features" - or in other words - the main part of the samples it the control.
I real world scenarios the things are opposite. The main approach is data handling.
So the percentage in profiling would move a lot.
A lot of the telerik controls have possibilities for optimization.
An example (since you have been talking about Editor) is the ToolProviderID
http://demos.telerik.com/aspnet-ajax/editor/examples/toolprovider/defaultcs.aspx
I would say there is some kind of a law. The more complex a control is the more possibilities for optimization exist. But they also tend to be solution specific.
So a simple control does what it does - not much space to gain performance.
A complex control allows you to make it fit your needs.
And a last (more general) thing about the ajax controls. Most of the controls have (very) rich client capabilities.
This results in many scripts - and the need to register a lot of things. (What you have seen when profiling).
BUT - on the other hand this gives you the power to do a lot of things directly on the client.
Which eliminates server roundtrips - and those roundtrips are the things which (in real world apps) consume most of the time.
And further they put pressure to your server - not so good in heavy load situations.
Let me bring an example:
You go by car: enter the vehicle, start it up, switch to a gear - go. 30 Seconds I would say.
Or use a plane: enter the vehicle, use a 20 point checklist and see if everything is OK. Start engine - next checklist.... 10 to 20 Minutes I guess.
So the rad controls and their capabilities tend more to be a plane - but they also bring this power which allows you to build high performance applications - even in very complex scenarios.
The "negative side" is that you pay for this with some kind of overhead - even in simple applications.
Last not least:
Controls (and their scripting behavior) do not (if you don't make real big mistakes) make your app slow.
The performance comes "from behind" - your algorithms, your database, your server...
Regards
Manfred
you question "Is it ok?" is the general question in performance tuning.
There only one instance who can answer this question: your customer :)
If he opens a page with hundreds of controls and it takes (just a number) 2 seconds - is this to long?
It depends on the situation - if this form opens after every letter he types in a textbox - NO much to slow.
If it is the "entry screen" (or "order confirmation screen") visited 2 times a day it would not be a problem.
One problem is the client hardware - and especially the browser (it's script engine).
The next thing - you said "I profiled your app" - which app? The samples I guess.
The samples (most of the time) are "untypical" - they are intended to show you the possibilities of the controls.
And except some sections (about data / performance) they are "optimized for features" - or in other words - the main part of the samples it the control.
I real world scenarios the things are opposite. The main approach is data handling.
So the percentage in profiling would move a lot.
A lot of the telerik controls have possibilities for optimization.
An example (since you have been talking about Editor) is the ToolProviderID
http://demos.telerik.com/aspnet-ajax/editor/examples/toolprovider/defaultcs.aspx
I would say there is some kind of a law. The more complex a control is the more possibilities for optimization exist. But they also tend to be solution specific.
So a simple control does what it does - not much space to gain performance.
A complex control allows you to make it fit your needs.
And a last (more general) thing about the ajax controls. Most of the controls have (very) rich client capabilities.
This results in many scripts - and the need to register a lot of things. (What you have seen when profiling).
BUT - on the other hand this gives you the power to do a lot of things directly on the client.
Which eliminates server roundtrips - and those roundtrips are the things which (in real world apps) consume most of the time.
And further they put pressure to your server - not so good in heavy load situations.
Let me bring an example:
You go by car: enter the vehicle, start it up, switch to a gear - go. 30 Seconds I would say.
Or use a plane: enter the vehicle, use a 20 point checklist and see if everything is OK. Start engine - next checklist.... 10 to 20 Minutes I guess.
So the rad controls and their capabilities tend more to be a plane - but they also bring this power which allows you to build high performance applications - even in very complex scenarios.
The "negative side" is that you pay for this with some kind of overhead - even in simple applications.
Last not least:
Controls (and their scripting behavior) do not (if you don't make real big mistakes) make your app slow.
The performance comes "from behind" - your algorithms, your database, your server...
Regards
Manfred
0
Steve Barak
Top achievements
Rank 1
Rank 1
answered on 18 May 2009, 06:53 PM
Manfred interesting response. I like your analogy of car vs plane
I too am using Telerik and am experiancing very poor performance all around (not just one specific control, but particularly grids).
The thing that troubles me the most is I was testing our app using Firefox and Google Chrome and the application is just flying. It is 2 to 3 times faster than in IE7 (or even IE8 which I recently started testing as well).
This leads me to believe that Telerik is not the culprit per say, however if the product cannot work with IE than what good is it?
As you know 80+ percent of all Internet users use IE.
Telerik must find a solution where either they come up with a work around or have Microsoft work with them to fix their browser. Something needs to be done here otherwise Telerik as a product is really not useable!
0
Hi there,
You can take a look at our Top Performance page for useful tips on the matter.
All the best,
Paul
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.
You can take a look at our Top Performance page for useful tips on the matter.
All the best,
Paul
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.
0
ManniAT
Top achievements
Rank 2
Rank 2
answered on 19 May 2009, 10:43 AM
@Paul: Thank you very much for this link - I've overseen it till now - a really great source for optimizing!
@Steve: We use telerik controls for more than 5 years. And due to customer requirements we also had to work with other control suites. The experience was let's say "mixed". We used some controls which (in special cases) offered an easier way to solve a specific problem. The problem - while there was (is) a "super easy way" to do thing X - it means lot's of work to do thing Y.
With telerik RAD controls we found a thing which sometimes needs little code or thing like this - but no matter what you do the effort is almost the same. In simple words - to do the thing X means a little customization - but for thing Y it means the same (little) work you have to do.
And last not least (if you are lazy like me) - support at telerik means more than "bug fixing" - it means "problem solution". In the years we used the telerik controls we often got running solutions from the support, just by asking "how could this be done".
About performance - or to stop talking of topic :)
Telerik controls offer a wide range of client functionality. This means scripting. And Microsoft does not offer the fastest script engine as we well know. It became a lot better with IE8 - but IE6 or IE7 has a noticeable lack of performance compared to FF or other browsers.
From my point of view performance means also "placement of work". In other words - I can do a lot of things at the server resulting in the fact that the client has less work. Or the opposite - let the client do most of the work - and save resources on the server.
There are mainly 3 parts involved in this game.
The server, the line and the client.
-- The line is the thing you can hardly predict in internet scenarios (in intranet things are different).
-- The client means the hardware and the browser - we don't have control over this (the same as for the line).
-- The server seems to be the easiest part in the thing - just add ram (cpu's) to speed it up.
In an intranet environment (limited number of users, extreme fast lines) you can build applications which use a massive amount of data transferred over the wire. And since you have very little clients (some hundred to some thousands) you can also let the sever do a lot of work.
This is the scenario where "primitive" controls like a repeater or native HTTP handlers (building tables with a loop) take place.
What we have here is a typical client server scenario where the client is a stupid unit - nothing more than a presentation layer.
And if some more clients are added - just upgrade the server a little bit.
In internet scenarios the things change a lot.
The wire is no longer "ultra fast" - sometimes (mobile scenarios or bad infrastructure) it can become really slow.
The number of clients changes from the well know 1723 users to an unpredictable number.
And depending on the solution you offer you often get a "punctual use". What I mean is (for an example) a site like a pizza order service.
While most of the day there is low traffic - in the noon time or at evening you'll have some hours of high usage.
The scalability of such a solution becomes (much) better if you let the client do most of the work. So every new client means almost nothing to the server since most of the work is done at the client.
And doing the work on the client means implicit (in most cases) that the amount of data transferred is very little. An important thing since the wire can be (very) slow.
The price for it is a dependency on the browser - or in the scripting engine of the browser.
The experience changes from "if you have a fast internet connection and run the site at 3am it is extremely fast" to "(almost) no matter what internet connection you have or at what time you run the application it is always running a the same speed" (a bit slow maybe with some browsers).
Which brings us to a thing called "baseline" or "acceptable speed". If a complex page takes one second in FF to display and 3 seconds in IE this is "bad performance" from the view of an IE user. But it does not really mean that this speed is not acceptable.
If it takes three seconds to display all possible things that I can place on my pizza - I wouldn't care.
If it takes three seconds for every single item I select it would be bad.
And here the rich client model of the telerik RAD controls takes place.
YES you are right - with IE it takes more time for the initial load. But after this you can't see a difference, as long as you make use of the things these controls offer.
I've built a lot of sites - and I never ran into a really problem with browser performance. The most optimization work I did was in the fields of "reduce the data transferred" and "optimize the server workload".
There have been scenarios where I had to do something on the client side. But this was not direct optimization it was more "application design".
A sample for this: I've had a scenario where the users needed to edit large number of record with a lot of fields. And it was complex (a lot of validation, several fields with HTML content and so on). The solution - an edit form as a modeless dialog. So the initial load took some time (a few seconds) and every subsequent call resulted in just a load of the content.
And YES - the first load of the "dialog" with IE took about twice the time it took with FF - but after this it stayed (almost) the same, no matter which browser was used.
Most important for me - the telerik RAD controls offer a lot of customization. For an example the Grid offers different "Hierarchial loading modes". So I can choose where (or when) to place the workload. Do it on the server, do it on the client, do it on loading, do it on demand...
In the beginning I was not very happy with this. Why do I have to tell the control to do the things I always need? Why doesn't it do these things "out of the box" (or as default)?
Later I learned that some of the modes I've never touched before a very useful in specific scenarios.
CONCLUSION:
You can change a lot of things the controls do - so it is easy to make them fit in your specific scenario.
And although IE is significant slower than other browsers it far beyond the point where I would call it "unusable".
Viewed from the opposite I could say: if I build my application in a way that it runs acceptable with IE - it will run even better (faster) with other browsers :)
Last not least: there are scenarios where "simple default controls" do their job very well. So to display a (let's say) shopping cart I don't need a grid - a repeater can do this job also.
And finally: every component (control) vendor has to live with this situation. And no one of them has the "power" to force Mircrosoft to build a faster script engine.
So I'm happy with the great client capabilities and the rich customization possibilities of the telerik RAD controls.
I didn't find anything better till now.
And if you say "something needs to be done otherwise Telerik as a product is really not usable" I guess you have a scenario which is not solved very well. Or to be a bit provoking: what's the name of the product which is useable in your case? :)
Regards
Manfred
@Steve: We use telerik controls for more than 5 years. And due to customer requirements we also had to work with other control suites. The experience was let's say "mixed". We used some controls which (in special cases) offered an easier way to solve a specific problem. The problem - while there was (is) a "super easy way" to do thing X - it means lot's of work to do thing Y.
With telerik RAD controls we found a thing which sometimes needs little code or thing like this - but no matter what you do the effort is almost the same. In simple words - to do the thing X means a little customization - but for thing Y it means the same (little) work you have to do.
And last not least (if you are lazy like me) - support at telerik means more than "bug fixing" - it means "problem solution". In the years we used the telerik controls we often got running solutions from the support, just by asking "how could this be done".
About performance - or to stop talking of topic :)
Telerik controls offer a wide range of client functionality. This means scripting. And Microsoft does not offer the fastest script engine as we well know. It became a lot better with IE8 - but IE6 or IE7 has a noticeable lack of performance compared to FF or other browsers.
From my point of view performance means also "placement of work". In other words - I can do a lot of things at the server resulting in the fact that the client has less work. Or the opposite - let the client do most of the work - and save resources on the server.
There are mainly 3 parts involved in this game.
The server, the line and the client.
-- The line is the thing you can hardly predict in internet scenarios (in intranet things are different).
-- The client means the hardware and the browser - we don't have control over this (the same as for the line).
-- The server seems to be the easiest part in the thing - just add ram (cpu's) to speed it up.
In an intranet environment (limited number of users, extreme fast lines) you can build applications which use a massive amount of data transferred over the wire. And since you have very little clients (some hundred to some thousands) you can also let the sever do a lot of work.
This is the scenario where "primitive" controls like a repeater or native HTTP handlers (building tables with a loop) take place.
What we have here is a typical client server scenario where the client is a stupid unit - nothing more than a presentation layer.
And if some more clients are added - just upgrade the server a little bit.
In internet scenarios the things change a lot.
The wire is no longer "ultra fast" - sometimes (mobile scenarios or bad infrastructure) it can become really slow.
The number of clients changes from the well know 1723 users to an unpredictable number.
And depending on the solution you offer you often get a "punctual use". What I mean is (for an example) a site like a pizza order service.
While most of the day there is low traffic - in the noon time or at evening you'll have some hours of high usage.
The scalability of such a solution becomes (much) better if you let the client do most of the work. So every new client means almost nothing to the server since most of the work is done at the client.
And doing the work on the client means implicit (in most cases) that the amount of data transferred is very little. An important thing since the wire can be (very) slow.
The price for it is a dependency on the browser - or in the scripting engine of the browser.
The experience changes from "if you have a fast internet connection and run the site at 3am it is extremely fast" to "(almost) no matter what internet connection you have or at what time you run the application it is always running a the same speed" (a bit slow maybe with some browsers).
Which brings us to a thing called "baseline" or "acceptable speed". If a complex page takes one second in FF to display and 3 seconds in IE this is "bad performance" from the view of an IE user. But it does not really mean that this speed is not acceptable.
If it takes three seconds to display all possible things that I can place on my pizza - I wouldn't care.
If it takes three seconds for every single item I select it would be bad.
And here the rich client model of the telerik RAD controls takes place.
YES you are right - with IE it takes more time for the initial load. But after this you can't see a difference, as long as you make use of the things these controls offer.
I've built a lot of sites - and I never ran into a really problem with browser performance. The most optimization work I did was in the fields of "reduce the data transferred" and "optimize the server workload".
There have been scenarios where I had to do something on the client side. But this was not direct optimization it was more "application design".
A sample for this: I've had a scenario where the users needed to edit large number of record with a lot of fields. And it was complex (a lot of validation, several fields with HTML content and so on). The solution - an edit form as a modeless dialog. So the initial load took some time (a few seconds) and every subsequent call resulted in just a load of the content.
And YES - the first load of the "dialog" with IE took about twice the time it took with FF - but after this it stayed (almost) the same, no matter which browser was used.
Most important for me - the telerik RAD controls offer a lot of customization. For an example the Grid offers different "Hierarchial loading modes". So I can choose where (or when) to place the workload. Do it on the server, do it on the client, do it on loading, do it on demand...
In the beginning I was not very happy with this. Why do I have to tell the control to do the things I always need? Why doesn't it do these things "out of the box" (or as default)?
Later I learned that some of the modes I've never touched before a very useful in specific scenarios.
CONCLUSION:
You can change a lot of things the controls do - so it is easy to make them fit in your specific scenario.
And although IE is significant slower than other browsers it far beyond the point where I would call it "unusable".
Viewed from the opposite I could say: if I build my application in a way that it runs acceptable with IE - it will run even better (faster) with other browsers :)
Last not least: there are scenarios where "simple default controls" do their job very well. So to display a (let's say) shopping cart I don't need a grid - a repeater can do this job also.
And finally: every component (control) vendor has to live with this situation. And no one of them has the "power" to force Mircrosoft to build a faster script engine.
So I'm happy with the great client capabilities and the rich customization possibilities of the telerik RAD controls.
I didn't find anything better till now.
And if you say "something needs to be done otherwise Telerik as a product is really not usable" I guess you have a scenario which is not solved very well. Or to be a bit provoking: what's the name of the product which is useable in your case? :)
Regards
Manfred
0
Steve Barak
Top achievements
Rank 1
Rank 1
answered on 19 May 2009, 01:49 PM
It is a home grown application. We use it strictly in house, we are a 50 people company.
I agree with you that once the page loads you can keep things real nice, problem is this is like an ERP style app where people constantly jump around from jobs to service tickets to purchase orders etc... and to make it worse, it is not a 1 second FF vs 3 seconds IE, it is like 2 seconds FF vs 5-6 seconds IE. When jumping around from here to there costs you 5-6 seconds per jump, it makes you not want to jump :)
Anyhow, I love the product I am just ranting. Before we started using Telerik we had very nice performance but the visual of the app was very poor. Now the visual is very consistent and rich but very slow. I am writing this in Google Chrome now, my new full time browser!
FYI, I just found a possible bug in Chrome where it removes spaces between words sometimes. It happenes when I posted here, and in our app when using Chrome.