I have had a look through lots of posts but can't seem to find anything on UIWebView load times and the kind of performance to expect.
I have an app that calls in a cached html page which is about 4.2KB in size. The view takes around 3.5 seconds to render through a wi-fi connection. How good or bad is this?
I'm trying to get the page as quick as possible but I can't really find anything more I can do. So I guess the question is, should I be getting better performance than this?
Any useful links would be appreciated.
It really doesn't have much to do with the size of the HTML. Although 4.2Kb is rather big. Rendering performance is mostly related to "what" it renders. For example, if you have lots of tables, or even worse -- nested tables --, then the rendering will be really slow. If you're HTML uses bad recursive entity definitions, it'll be horribly slow too. I would recommend taking full advantage of HTML5 for complex rendering.
Related
I am attempting to develop a cms system that will use tags to display similar content. For example, underneath the news section there will be articles, blogs, news and forum questions that share the same tags. There will be no more than 5 items in each list.
I am considering 2 options for displaying this related content and am wondering if developers with more experience than myself would recommend one over the other?
Speed is the primary goal, because we have equally maintainable ways of executing both options.
Option 1 - Output Caching RenderAction Results
For each 'similar content' section, render a child action on the corresponding controller and cache the output. This feels more in the spirit of MVC, and would be light on DB calls. But with 5 'similar content' lists, that would equal 6 full MVC cycles for each page request.
I've read that RenderAction can still be expensive, even though it has improved in the last couple of years.
Option 2 - RenderPartials with DB Queries for Each
Alternatively, for each 'similar content' section, we could query the db and use RenderPartial to display the output. Although this would require a small DB query for each section (5 items or less), I'm wondering how that would compare with the performance saved by NOT calling RenderAction.
I've frequently read how much faster RenderPartial is compared to RenderAction.
Essentially your choice boils down to which is faster: RenderAction with an already cached result or 5 DB queries?
When you look at it that way, you really are talking about one solution with no network latency and one solution with network latency (sending the query to the database and receiving a response). Any solution that removes network latency is de facto faster than an alternative with network latency.
Also, bear in mind that purists like to talk about how one thing or another is "slow" compared to some other way. Yes, child actions will always be slower than partials because child actions go through the whole routing infrastructure and then finally to the Razor template engine whereas partials just go directly to the Razor template engine. But, we're talking about highly optimized, compiled code running in memory. "Slower" is measured in milliseconds or even nanoseconds. Sure, those can add up over time, and if you did something crazy like render 50 child actions in a single view, you might see some noticeable performance loss, but this will typically not be an issue worth worrying about in 99.9999% of cases.
Just design your application in the way that makes the most sense for your application and stop worrying about a millisecond here or there.
As you know, if we use the form helper something like select_tag all the generated HTML's indent comes back to the very left.
Then generated HTML source looks ugly.
How do you handle this problem?
and does it matter to SEO?
As long as its valid HTML then search engines won't care about your whitespace/layout. Infact they can handle even invalid mark up to be honest. You don't get bonus points for having a clear HTML layout though I'm afraid.
Nice layouts make development/debugging easier and you should at least try to make it look pretty. But then using code generators like this it not always possible.
Focus on getting it working well and worry about prettying it up later if you have time ;)
I'm sure there is a way to modify the output if Rails is still as awesome as it used to be last time I had a play with it.
I use the erector gem to create my views, erector is basically an HTML-DSL in plain ruby which, among other things, allows to pretty_print your HTML. This is usually just done during development, as the additional whitespace would just increase the page size, burn bandwidth and slightly slow down the browser.
For this reason I cannot imagine that search-engines care at all. They just might have to do a little more work, so they might rank it a little lower, but I even doubt that much. They might care for valid HTML, that is another advantage of erector (and other templating languages as HAML and the like).
I am trying to optimize my code as much as possible. I use a lot of partial files like this:
#if (Model.PageMeta.Sidebar == PageMetaSidebar.Small) { Html.RenderPartial("_SmallSidebar"); }
..
..
..
Can someone tell me if there is a performance overhead with this. I understand that Razor views are compiled. Is it the case that when the page is displays there is another disk read to get the data for each of the partial files that I use. If that's the case then how much additional overhead could I expect with for example 5 RenderPartials on my layout page.
There will be no noticable performance hit at all here as the partials are just pulled in on the asp.net web server before streaming the resultant HTML back to the browser. This is not an expensive disk read to do and won't appear any slower than if it was a single cshtml. Obviously partials should be used if the same partial view is reused in many views. If only used in a single view then it's just a matter of clarity splitting it into a separate partials to separate parts of your model into different views.
Note you can also just use:
#Html.Partial("YourPartial")
rather than using RenderPartial. This will look in the local view folder then in shared if not found.
I don't think using RenderPartial ~5 times is going to have a significant enough impact to design your pages poorly. If it makes sense to pull the logic out (makes the page cleaner, used by multiple views, etc.) then do it. If you notice significant performance issues then you should look at them at that time, but don't prematurely optimize and create a poor design because you THINK it might slow something down.
If you like to get a better understanding of potential performance hits you might want to play around with the mvc-mini-profiler.
Please note though that I'm not advocating pre-mature optimization. However, using profiling tools might give you a better understanding of potential bottlenecks, thus helping you avoid them in the future.
In keeping with the DRY-principle I try to use partials as soon as I am repeating a particular pattern more than once or twice. As a result, some of my views consist of ten or more different partials. I am worried that this might have a negative effect on the overall performance. Some programming books compare the use of partials with the use of methods. So should I use the same rationale to determine when to use them?
What is the best practice regarding size and quantity of partials in a Rails project?
I like your practice already: Once you've repeated view code twice, refactor it out to a partial. Tim's right that you can speed it up as necessary after it's been profiled and after it's been proven necessary.
Here is my one caveat: If you work with professional designers who handle the views, it may be easier over the long term to have rather repetitive view code. Some people have a hard time searching through partials and "seeing" how they all fit together. I've found it easier with those people to let them manage the whole shebang and update more than one file if they need to. Optimal? Not to us as programmers, but designers are more often used to seeing most of the HTML in one or three files rather than 20. :)
Remember the rules of optimization!
If, once your application is complete, your views are too slow, use something like New Relic to find out where the slowdown is occurring. There are a lot of places that might be, but it's unlikely to be in your partials.
Can I use partials as much as I want or do I have to restrain myself to avoid bringing my views to a crawl under much traffic?
There's an obvious overhead using partial but this isn't something you should probably worry about.
Partials are files. When you render an action without partials, your action "costs" 1 file (that's not totally true, but this is to simplify the explanation).
If your action renders 4 partials, you end up with a cost of 5. This means, you have 4 additional IO calls and the real cost for each call depends on your server load, server performances and so on.
But does this cost matter? In my experience, for the 99% of times no. Also noteworthy, the benefits of using partials in terms of code readability and maintainability usually are worth the choice.
If performances must be a key feature, you should probably look for speed and improvements elsewhere.
Remember: Ruby is not a super-fast programming language and code expressiveness always took the first place in favor of performances. Rails implicitly agree to this convention, albeit the Rails team has always focused on performances (and Rails 3 it's the practical demonstration there's always place for improvements)
That said, you can safely use partials and reduce the application overhead with some clever caching mechanism. For example, you can place collection rendering within a cache block so that a render collection statement will be executed only once then your app will simply load 1 cache file instead of 10 un-cached partials.
One of the most sneak errors I made many times at the beginning was to worry about performances in the wrong way, that said, without actually running benchmarks. I remember once when I was trying to drop one single database query in favor of an hard coded hash because "the query costs", without realizing there was an other stupid query that was loading an entire table collection without the include statement, that resulted in running the second query 3 times slower.
So, if you really care about performance, you probably shouldn't avoid using partials but instead make sure you are taking advantage of all the other features Rails provides you to scale your application.