Is there any evidence that suggests including a whole namespace in c# slows things down?
Is it better to do this
System.IO.Path.Combine....
Or to include the whole System.IO namespace?
It's much better to include the namespace in a using statement at the top of your class. The compiler doesn't care; it will emit the same IL both ways, and your code will be shorter and easier to read.
No matter what, including the entire namespace will not slow down production code.
Will it slow down the compiler? That's debatable, but C# compilation is so fast it's unlikely. A far worse offender in slowing down compilation is a large number of projects in your solution.
It makes no difference... it's purely for readability and in cases where you have naming collisions.
It will not slow down your production code, however it could slow down your coding as the IDE has to show you more options and you have to pick through more possibilities when looking at code completion lists.
Adding extra namespaces can affect the compile time of your application. It's unlikely to be noticable in most applications but extremes could make it visible.
It however has no impact on the runtime performance of your application.
No, the compiler is fast enough. Not sure what else I can add :)
Related
If I put all classes of a project in the same namespace all classes are available everywhere in the project. But if I use different namespaces not all classes are available everywhere. I get a restriction.
Does using namespaces affect the compile time somehow? Since the compiler has less classes in each namespace and not all namespaces are used all the time he may have a little less trouble finding the right classes.
Will using namespaces affect the applications performance?
It won't affect the execution-time performance.
It may affect the compile-time performance, but I doubt that it would be significant at all, and I wouldn't even like to predict which way it will affect it. (Do you have an issue with long compile times? If so, you may want to try it and then measure the difference... otherwise you really won't know the effect. If you don't have a problem, it doesn't really matter.)
I'm quite sure, that putting classes in namespaces does not effect the compile time significantly.
But beware, that you might lose your logical project-structure, if you put every class into the same namespace.
I (and the Resharper) suggest to use namespaces that correspond with the file location (which corresponds with the project structure).
You should use namespaces according to your logic and ease of human readability and not for performance issues.
edit typos
Hi,
This is possibly a moronic question, but if it helps me follow best practice I don't care :P
Say I want to use classes & methods within the System.Data namespace... and also the System.Data.SqlClient namespace.
Is it better to pull both into play or just the parent, ie...
using System.Data
using System.Data.SqlClient
or just...
using System.Data
More importantly I guess, does it have ANY effect on the application - or is it just a matter of preference (declaring both the parent and child keeps the rest of the code neat and tidy, but is that at the detriment of the application's speed because its pulling in the whole parent namespace AND then a child?)
Hope thats not too much waffle
It doesn't make any difference to the compiled code.
Personally I like to only have the ones that I'm using (no pun intended) but if you want to have 100 of them, it may slow down the compiler a smidge, but it won't change the compiled code (assuming there are no naming collisions, of course).
It's just a compile-time way of letting you write Z when you're talking about X.Y.Z... the compiler works out what you mean, and after that it's identical.
If you're going to use types from two different namespaces (and the hierarchy is largely illusional here) I would have both using directives, personally.
Click Organize->Remove Usings and Visual Studio will tell you the correct answer.
Firstly, it has no effect on the application. You can prove this by looking at the CIL code generated by the compiler. All types are declared in CIL with their full canonical names.
Importing namespaces is just syntactical sugar to help you write shorter code. In some cases, perhaps where you have a very large code file and are only referring to a type from a specific namespace a single time, you might choose not to import the namespace and instead use the fully-qualified name so it's clear to the developer where the type comes from. Still, though, it makes no difference.
Express what you mean and aim for concise, clear code - that's all that matters here. This has no effect on the application, just on you, your colleagues and your future workers brains.
Use whatever happens when write your type name and press Ctrl + .,Enter in VS.
According to the question: Is C# code faster than Visual Basic.NET code?
Was said that C# and VB.NET generates the same CLR code at the end.
But in the case when I'm using codebehind and inline code, are there different performance (ignoring the language used)?
Inline code can require compilation the first time the request is made. After that (or if it's precompiled), there's absolutely zero difference between them.
By the way, even if it requires compilation, the speed difference should be insignificant as ASP.NET will have to compile a source file anyway. The difference will come down to a adding a few lines of code in a large source file!
Yes, ish... If you're compiling at run-time you're always going to be more expensive than something which doesn't have to, but that compile will be cached (if you will) after the first request so you'll get zero difference from then on.
There's probably somone who knows another reason, but to my mind the only realistic purpose for inline is the ability to make hot fixes without a rebuild + redeploy: the kind of thing you might do in small or early stage dev projects. Personally I also find inline just a little... aesthetically displeasing.
The aspx pages have to be parsed and compiled anyway as ASP.Net turns them into classes that inherit from the codebehind (hence the inherit attribute in the page directive) so compilation is necessary in either case. The difference between the two for first runs is going to be negligible unless we're talking about several thousand lines of code.
But I agree with anna: inline is icky.
I'm not sure whether the resulting assembly produced has the AllowOptimize attribute set to on or off. I can find no documentation which indicates this either way.
As such it is possible that the resulting code is not optimized by the JIT in quite the same way.
I doubt this makes a significant difference if any (like I said this might be controlled in some other way) but certainly it could impact certain operations if it, for example, disabled inlining and you had a large, extremely tight loop. Such a construct would probably be a poor choice within an asp.net page so this shouldn't be an issue.
No. Unless you are using web project the site needs to be compiled on the first hit. That affects inline as well as code behind to some extend. After that they run pretty much at the same speed.
Do class, method and variable names get included in the MSIL after compiling a Windows App project into an EXE?
For obfuscation - less names, harder to reverse engineer.
And for performance - shorter names, faster access.
e.g. So if methods ARE called via name:
Keep names short, better performance for named-lookup.
Keep names cryptic, harder to decompile.
Yes, they're in the IL - fire up Reflector and you'll see them. If they didn't end up in the IL, you couldn't build against them as libraries. (And yes, you can reference .exe files as if they were class libraries.)
However, this is all resolved once in JIT.
Keep names readable so that you'll be able to maintain the code in the future. The performance issue is unlikely to make any measurable difference, and if you want to obfuscate your code, don't do it at the source code level (where you're the one to read the code) - do it with a purpose-built obfuscator.
EDIT: As for what's included - why not just launch Reflector or ildasm and find out? From memory, you lose local variable names (which are in the pdb file if you build it) but that's about it. Private method names and private variable names are still there.
Yes, they do. I do not think that there will be notable performance gain by using shorter names. There is no way that gain overcomes the loss of readability.
Local variables are not included in MSIL. Fields, methods, classes etc are.
Variables are index based.
Member names do get included in the IL whether they are private or public. In fact all of your code gets included too, and if you'd use Reflector, you can practically read all the source code of the application. What's left is debugging the app, and I think there might be tools for that.
You must ABSOLUTELY (and I can't emphasize it more) obfuscate your code if you're making packaged applications that have a number of clients and competition. Luckily there are a number of obfuscators available.
This is a major gripe that I have with .Net. Since MS is doing so much hard work on this, why not develop (or acquire) a professional obfuscator and make that a part of VS. Dotfuscator just doesn't cut it, not the version they've for community.
Keep names short, better
performance for named-lookup.
How could this make any difference? I'm not sure how identifiers are looked up by the VM, but I'm pretty sure it's not doing a straight string comparison lookup. This would be the worst possible way to do it.
Keep names cryptic, harder to decompile.
To be honest, I don't think code obfuscation helps that much. Most competent developers out there have already developed a "sixth sense" to figure out things quickly even if identifiers like method names are totally unhelpful since very often the source code they need to maintain or improve already has these problems (I am talking about method names like "DoAllStuff()").
Anyway, security through obscurity is usually a bad idea.
If you are concerned about obfuscation check out .NET Reactor. I tested 8 different obfuscators and Reactor was not only the cheapest commercial one, it was the second best of the bunch (the best was the most expensive one, Dotfuscator Gold).
[EDIT]
Actually now that I think of it, if all you care about is obfuscating method names then the one that comes with VS.NET, Dotfuscator Community Edition, should work fine.
I think they're added, but the length of the name isn't going to affect anything, because of the way the function names are looked up. As for obfuscation, I think there are tools (Dotfuscator or something like that) that basically do exactly what you're saying.
I know VS2008 has the remove and sort function for cleaning up using directives, as does Resharper. Apart from your code being "clean" and removing the problem of referencing namespaces which might not exist in the future, what are the benefits of maintaining a "clean" list of using directives?
Less code?
Faster compilation times?
If you always only have the using directives that you need, and always have them appropriately sorted, then when you come to diff two versions of the code, you'll never see irrelevant changes.
Furthermore, if you have a neat set of using directives then anyone looking at the code to start with can get a rough idea of what's going to be used just by look at the using directives.
For me it's basically all about less noise (plus making Resharper happy!).
I would believe any improvement in compilation time would be minimal.
There's no runtime impact. It's purely compile time. It potentially impacts the following:
Less chance for Namespace collisions
Less "noise" in the code file
Very explicit about which namespaces and possible types to expect in the file
Using the menu to remove unused and Sort means more consistency with using statements among the devs. Less chance of dumb checkins just to fix it up.
Less noise.
Clear expectation of what types are used ("My UI layer depends upon System.Net. Wow, why?")
Cleaner references: if you have the minimal set of using statements, you can cleanup your references. Often I see developers just keep throwing references into their projects, but they never remove them when they're no longer needed. If you don't have anything that actually needs a reference (and a using statement counts), it becomes trivial to clean up your references. (Why would you want to do that? In large systems that have been decomposed into components it will streamline your build dependencies by eliminating the unused deps.)
For me, a clean list of using statements at the beginning can give a good understanding of the types to expect.
I saw a decent gain in compile time a few years ago when I first installed ReSharper (on an 18 project solution). Since then its just been about keeping it clean.
I can't speak to the benefits in compile time and performance, but there's a lower chance of namespace collisions if you have minimize your using declarations. This is especially important if you are using more than one third party library.
There is one compile-time difference: when you remove a reference, but still have a using directive in your code, then you get a compiler error. So having a clean list of using directives makes it a little bit easier to remove unused references.
Usually the compiler removes unused references, but I don't know if that works when a using is in the code.