This might be a pretty strange question in the eyes of some of you out here, but I really wonder if comments in my code will slow down the execution time of the pages I make.
I have some Classes / WebControls that required alot of comments to make everything clear and quickly readable to other people that will have to deal with my code and now wonder how ASP.Net deals with my comments. Will comments be stripped from my code at compile time or how is this all done?
I should be more specific: I mean comments in my code-behind in C#.
Comments serverside in C# won't do anything but a slight increase in compiletime.
Comments in javascript of course increase the downloadsize. But since you usually minify javascript on production systems, and thus strip out the comments and whitespace it doesn't matter in practice.
Since html minification on dynamically generated pages isn't that common, comments in html slow you down a bit, but they typically are so few that it doesn't matter in practice either.
Comments on the aspx pages (like in javascript etc.) are slowing down the page because it is content that needs to be downloaded. For JavaScript you might use a minimizer and have a minimized version of the javascript on the production system.
For c# code... it does not make a difference since the comments are not compiled into the assembly.
No. Only exception is when you have an exorbitant amount of HTML (<!--) comments because this will require extra time to transfer your HTML over the internet. All C# comments will be striped when compiled.
If the comments are in the .aspx page, it will depend on whether they're HTML comments or server-side comments. As Pieter points out, HTML (!<--) comments have an impact because they get transferred over the network.
Generally speaking, the more that gets sent to the browser, the longer it will take your pages to load. (It also puts additional load on your server - increased bandwidth usage, and most likely a small increase in CPU load simply because the server has to work harder to send more data.)
That's why ASP.NET supports server-side comments. If you use the !<%-- ... --%> syntax instead, the contents of the comment will not be sent to client. The best way to know for certain what's actually being transferred is to View Source in the browser to see what came across.
Scott Guthrie posted about this back in 2006: http://weblogs.asp.net/scottgu/archive/2006/07/09/Tip_2F00_Trick_3A00_-Using-Server-Side-Comments-with-ASP.NET-2.0-.aspx
Related
I am currently rewriting a large website with the goal of replacing a large number of page/form submittals - with AJAX calls. The goal is to reduce the amount of server roundtrips - and all the state handling on pages that are rich with client .
Having spent some time considering the best way forward with regards to performance - my question is now the following.
Will it lead to better performance to have just one single aspx page that are used for all AJAX calls - or will it be better to have a aspx page for every use of AJAX on a given webage?
Thank you very much for any insights
Lars Kjeldsen
Performancewise either approach can be made to work on a similar order of magnitude.
Maintanancewise, I prefer to have separate pages for each logical part of your site. Again, either can work, but I've seen more people make a mess of things with "monolithic" type approaches. Single page you'll need a good amount of skill structuring your scripts and client side logic. Well done there isn't a problem, however, I just see more people getting it right when they use separate pages for separate parts of the site.
If you take a look at the site http://battlelog.battlefield.com/ (you'll have to create an account) you'll notice a few things about this it.
It never refreshes the page as you navigate the website. (Using JSON to transmit new data)
It updates the URL and keeps track of where you are.
You can use the updated URL and immediately navigate to that portion of the web-application. (In this case it returns the HTML page)
Here's a full write up on the website.
Personally, I like this approach from a technology/performance perspective, but I don't know what the impact it will have on SEO since this design relies on the HTML5 History state mechanism in JavaScript.
Here's an article on SEO and JavaScript, but you'll have to do more research.
NOTE: History.js provides graceful degradation for Browsers that do not support History state.
At my previous job, our team architect was strongly against including any server side code in the markup, even simple ID's, so this code would not be allowed to get checked in:
<script>
var el = document.getElementByID('<% SomeElement.ClientID %>')
</script>
instead you had to inject it into javascript via Page.ClientScript.Register...
His reason was that asp.net has to recompile a page every time if it has those server code includes.
That didn't sound right for me but I couldn't find any proof of either.
Any ideas? Does that change performance or not? I know that server side code in markup is not good because of difficulties in debugging and readability and the whole idea of separatin gcode form markup, but I am only interested in performance differences.
Thanks!
Your architect is wrong.
ASP.NET compiles a page once, regardless of whether or not it contains any C# code. It will recompile the page only if it detects that the ASPX file was changed since last compilation.
Use a profiling tool (like dotTrace from JetBrains) to definitively tell you the performance metrics. Write 2 pages...one with and one without server-side stuff...and test.
I know the question is a bit subjective, but often there is a consensus as to a whether a style should be avoided or is considered harmless.
I have elements of actual HTML mixed in with a lot of my ASP.NET markup. I don't know enough about what goes on in the background to determine whether this should be avoided or if it is harmless.
I recently read that all styling elements should be left out of ASPX files and relegated to CSS; this seems wise for a variety of reasons.
I'm wondering if HTML code should be replaced by corresponding ASP as it is harder to control from the code behind, or if it is perhaps recommended to put actual HTML code as it is less do to when the page is rendered.
When the asp.net compiler parses your .aspx files, it converts everything that's not already a runat="server" control into an <asp:literal> control so that it can construct code (be it c# or vb.net) from your markup that generates the page.
Ultimately there's probably very little difference, performance wise, but if you have no reason to manipulate a particular element from your codebehind it probably makes sense to leave it as "pure" HTML, for readability if nothing else.
I think it's nothing wrong to put HTML in ASPX page if this part is actually static, for example I often to use HTML tables in ASPX. Page will be rendering faster if you don't use server controls where it's not necessary.
I like to keep my HTML just HTML so that it is clear to anyone else looking at my code in the future what elements are potentially referenced in server side logic without having to compare code behind files to .aspx pages to see what is used in server side code or not.
That way someone can easily tell from looking at the "design" of the page what elements are processed on the back end. Either way, like noted probably not a major performance difference, but more a good practice IMO.
I'm interested to hear from other developers their opinion on an approach that I typically take. I have a web application, asp.net 2.0, c#.
What I usually do to write out drop downs, tables, input controls, etc. is in the code behind use StringBuilder and write out something like sb.Append("
I don't find myself using to many .net controls as I typically write out the html in the code behind. When I want to use jQuery or call JavaScript I just put that function call in my sb.Append tag like sb.Append("td...onblur='fnCallJS()'.
I've gotten pretty comfortable with this approach. For data access I use EntitySpaces.
I'm just kind of curious if this sort of approach is horribly wrong, ok depending on the context, good, time to learn 3.0, etc. I'm interested in learning and was just looking for some input.
Edit
After reading the comments here it sounds like I should take a look at MVC. I've not done that yet. The only hesitancy in doing so is that the existing project is just that, existing. There is a lot of code already done the way I explained and it is hard to imagine what would be involved in changing it, advantages of doing so, and just learning what that would take.
The other thing I'm taking away from the comments is that my code behind should really not include much of the sb.Append code, whereas now it is filled with it in numerous functions. To me it is not messy but that is because I know what each function does and can look at it and see, oh that writes out x, y, and z.
It's not uncommon for me to just have a div on the .aspx part and then build up the .innerHtml of that with the StringBuilder in the code behind.
Thanks again for the comments. I'm thinking as I'm reading them.
I typically write out the html in the code behind.
That part is a little odd, and not something I recommend for webforms. If you want to do that, consider an asp.net mvc project instead.
In webforms, you really want the meat of your html to live with the markup rather than the code. The two should remain separate. You also don't want a huge stringbuilder that encompasses your entire page. This will force you to keep the entire page in memory twice (once for the stringbuilder bytes and once for the built string at the end) rather than writing the page to the response stream as it's built. That means more memory per request, which can really kill scalability.
To those ends, I would abstract distinct portions of your stringbuilder code into custom/user controls that you can use in the aspx markup. These controls can use a stringbuilder to create their output. This means you only need to keep enough html markup in memory to render one control at a time. It also allows you to more easily re-use common markup across pages or even sites.
There are times when you need to generate some HTML in your code behind, but in general, you want to leave the HTML where it belongs, and that's seperated from your code. The VS IDE is a pretty good HTML editor. Use it.
I'm going to go out on a limb and guess you may have come from a "Classic" ASP (vbScript) or PHP background.
My back ground is "Classic ASP" and my first attempts at the Webforms Model were pretty much the same as yours, once I started usnig them and understanding them I've never looked back. There is a disctinct learning curve though in understanding how the page life cycle interacts with the various WebForm controls.
Look up the various threads on ASP.net WebForms vs MCV to see which suits your projects needs the best. MVC Isn't a magic cure-all but in many respects may be more familiar if you're from a "Classic ASP" or PHP backgound.
From a practical perspective, assuming you're sticking with WebForms, if there is the possibility of other developers becoming involved in the project you aim towards using more of the inbuilt controls where you can as that is more than likely what they will be familiar with. Stating the obvious, the more you use the controls the more you will become familiar with what they can and can't do and before to long you will find yourself writing your own controls to fill the gaps or finding existing 3rd party controls.
A big problem you have with that it can get pretty messy... having to escape all the " or messing with carriage returns. Sure YOU can program around that, but what if you want to copy/paste code? sounds like a nightmare and WAY more work than it's worth.
It sounds like you should be writing a custom control and using HtmlTextWriter to write the markup.
Or perhaps more appropriate would be a user control, with markup in the aspx page and anything else in the code behind.
If you're using this approach, you should migrate your development efforts to ASP.Net MVC. Whereas ASP.Net actively tries to abstract the HTML, CSS, JavaScript, etc. away by using web controls, ASP.Net MVC is built around a paradigm of directly controlling the markup itself (though that may arguably be the least of the differences between the two - you should definitely read up on it to at least know the alternatives, even if you stick with ASP.Net in the long run).
Otherwise, what you're doing works if done properly (though you'll be fighting the framework the whole way), though I'd recommend using a StringWriter instead. It uses a StringBuilder internally so the performance characteristics are the same between the two, but the semantics are more consistent with the rest of the .Net framework (e.g., Write vs. Append).
I think this approach kind of defeats the purpose of what webforms was trying to accomplish (separating markup and code).
I know this thread is kind of old and has been answered really well, I just thought I would "append" (pun intended) my answer since I am working with code that was mentioned in the question.
ALL the markup is in the C# classes and they created a StringBuilder object to append all the html and JavaScript strings. This has made it very difficult to read the code and see what's going on, and what if they want to change the markup/design of the front-end? Now, I've got a heck of job on my hands having to go in and refactor all that markup in the classes, when it would be so much easier to change the .aspx pages and connect the data model to those pages.
In my humble opinion, I can't find a good reason to put any markup in your classes/code behind. They are for logic only. Plus, it makes it difficult to test and debug Javascript. That's my two cents. K.
do you think it would be difficult to write a framework where mvc compares last html it output to the current html we want to output, and instead of sending the entire html, figure out what has changed and generate js code that will do the updating as compared to previous html? (presuming nothing was manually changed on the client using js)... maybe an idea for a codeplex project? or maybe something like this exists? if so, do tell. thanks.
I think it's an interesting question, but one without a practical solution..
If I understand correctly you want to generate a diff from the current DOM into a new one, and you want to generate this change script (which is javascript executed client side) on the server.
The issue with that is that in order for the server to generate a diff, it needs to know what the previous DOM structure was in order to compare it with the new one (i.e. the new html page)
The only ways I can think of are:
1. The client sends back the full current page or some representation of it.
2. The server stores a copy of the previous page.
The problem with #1 is that you've already negated any performance benefit you from it. Sending a full page back to the server is just as bad or worse than sending it from the server to the client. You can achieve the same effect by requesting the full page body via AJAX and replacing it, and it would be just as efficient and simpler to implement.
The problem with #2 is now the server needs x copies of each page where x is the number of users. That's a lot of memory, unless you're persisting it to disk, in which case that's a a moderate sized disk write for every request. Then there's the problem of figuring out how long to keep these around, because if someone visits the site once, you don't want to keep it around forever.
The performance of either situation is most likely going to be worse than just getting the full page and will only get worse with more users.
That's not including the complexity of actually getting it right. I think hypothetically it could be done, but other than as a fun experiment there aren't any practical benefits that would outweigh the cost of such a solution, which is why I doubt you'll find one.
Have you considered caching? E.g. Caching in asp.net-mvc
Will be more straightforward and it makes more sense to me too.
You would need to save the state of any client at your server, and no response could be cached anywhere because every client needs a different response.
Even if this is possible, it would make no sense in the "HTTP world" imho.
You are attempting to suggest a solution for a problem that has already been solved. AJAX solved your question. You can use AJAX requests to load html that you know will change thus saving round trips.