|
The Concat method is slightly faster than the others. The Format method and your use of StringBuilder is virtually the same, as the Format method uses a StringBuilder and the AppendFormat method.
When you send the values to the Format and AppendFormat methods, they will be boxed. That means that a new object is created on the heap and the integers are stored in this object. Using the Concat method avoids the boxing.
If you want to use a StringBuilder, this is a better approach:
lblScore.Text = new StringBuilder().Append(correctNums).Append('/').Append(numberOfTurns).ToString();
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Number 2 is the right way, number 1 is the wrong way and number 3 does something entirely different to 1 & 2 (It does not assign a variable to lblScore). If it did assign str.ToString() to lblScore then it would be mostly the same as 2, but with the worthless overhead of creating a StringBuilder. If however you were appending a greater number of strings to the output then 3 would be the better way to approach the problem.
|
|
|
|
|
J4amieC wrote: Number 2 is the right way, number 1 is the wrong way
I wouldn't say right or wrong, it's more of which is better for the given circumstance
only two letters away from being an asset
|
|
|
|
|
Compiler changing concatenation with + to a stringbuilder asside, there is never a good reason to concatenate strings using +. Ever.
|
|
|
|
|
I would disagree, its a matter of preference. I see nothing wrong with something like "Some string: " + x, depending on the circumstance it is being used in.
As Guffa points out there may be some boxing that is occurring with StringBuilder and Format which could be avoided.
only two letters away from being an asset
|
|
|
|
|
Mark Nischalke wrote: I see nothing wrong with something like "Some string: " + x
I see nothing right with it, and no reason to use it over either of:
String.Format("Some string: {0}",x) or String.Concat("Some string: ",x)
|
|
|
|
|
You realise that using the + operator and using the String.Concat method produces identical code?
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
That is a COMPLETELY INVALID statement...I can't tell you how wrong that is. StringBuilder and String.Format are only useful and more performant in certain scenarios, not all. If you are joining thousands of string parts, StringBuilder will definitely be more efficient. If you are "formatting" a string, and you need localization support and the like, String.Format is your friend. However, for smaller concatenations where you know the number of parts involved, nothing beats the performance of a basic concat. Research it.
|
|
|
|
|
j4amieC you are write I did not write the full code in the third case, but yes the StringBuilder does assign the text to the lblScore.
Can you tell me why concatenating strings is not a good idea in this case. Does it leave string objects in memory? Or is there any other reason?
|
|
|
|
|
humayunlalzad wrote: Can you tell me why concatenating strings is not a good idea in this case.
Concatenate 10,000 strings using + and time it.
Now concatenate the same 10,000 strings using a stringbuilder.
Compare the times.
|
|
|
|
|
J4amieC wrote: Concatenate 10,000 strings using + and time it.
Now concatenate the same 10,000 strings using a stringbuilder.
Compare the times.
Here you go:
Concatenating using + operator 10000 times: 3.50 ms.
Concatenating using StringBuilder 10000 times: 5.03 ms.
Concatenating using String.Format 10000 times: 5.97 ms.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
J4amieC wrote: number 1 is the wrong way
Not at all. There is absolutely nothing wrong with using the Concat method to concatenate strings.
J4amieC wrote: If it did assign str.ToString() to lblScore then it would be mostly the same as 2, but with the worthless overhead of creating a StringBuilder.
That is exactly how the String.Format method does it. The method that you say is the "right way" also has the worthless overhead of creating a StringBuilder, so you contradict yourself...
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Actually, #1 is the best way for his situation. A concatenation of up to 12 strings is much faster than either a StringBuilder or String.Format. StringBuilder incurrs overhead by keeping the strings on the heap until you call ToString(). String.Format has a variety of processing overhead that is not necessary in this case. When you know explicitly the number of string parts you need to join, and the order they will be joined in, a concat (up to 12 parts) will always be faster...significantly less overhead. Contrary to popular opinion, a single memory allocation and concat operation is involved in small concatenations. Only use an alternative method when the number of parts and/or their join order is unknown, or when you have more than 12 parts to join.
|
|
|
|
|
My apologies...a string concat requires 2 allocations, not 1. For a comparison of concat vs. StringBuilder, take a look at this article:
http://blogs.msdn.com/ricom/archive/2004/03/12/performance-quiz-1-of-a-series.aspx
Concat: 4 calls, 2 allocations, 94 bytes
StringBuilder: 30 calls, 5 allocations, 184 bytes
|
|
|
|
|
If that's all I'm doing I use the second, but with more line breaks.
I wouldn't be concerned about the relative efficiency of those particular statements; particularly when dealing with a GUI.
But that's just me.
|
|
|
|
|
I had written code to create excel chart sometime back. Thanks to poor documentation I had done, I cant recall significance of "-4167". Can anyone help? Here is the code block:
objClassType = Type.GetTypeFromProgID("Excel.Application");
oExcelApp = Activator.CreateInstance(objClassType);
oProcess = System.Diagnostics.Process.GetProcessesByName("EXCEL");
oWorkBooks = oExcelApp.GetType().InvokeMember(
"Workbooks", BindingFlags.GetProperty, null, oExcelApp, null);
oArgs = new object[1];
oArgs[0] = -4167; <--- this one right here
oExcelWbk = oWorkBooks.GetType().InvokeMember(
"Add", BindingFlags.InvokeMethod, null, oWorkBooks, oArgs);
The word "politics" describes the process so well: "Poli" in Latin meaning "many" and "tics" meaning "bloodsucking creatures."
|
|
|
|
|
Tut tut - a google search for 'excel 4167' only returns 191000 results! It looks like -4167 refers to the type of a worksheet object.
It definitely isn't definatley
|
|
|
|
|
I have tried and still trying to search it. Still no success.
The word "politics" describes the process so well: "Poli" in Latin meaning "many" and "tics" meaning "bloodsucking creatures."
|
|
|
|
|
This search[^] worked fine for me - note that I didn't search for '-4167' as excel would then search for pages that didn't contain 4167. The first link has the detail I mentioned.
It definitely isn't definatley
|
|
|
|
|
Hunted[^]
I recommend this[^] article to myself. 
The word "politics" describes the process so well: "Poli" in Latin meaning "many" and "tics" meaning "bloodsucking creatures."
|
|
|
|
|
I only pass 1 argument to the workbooks.add method, and it's a path string to the template file.
addMethodInfo = workbookType.GetMethod("Add");
addMethodInfo.Invoke(_workbooksObject, new Object[] { template })
Perhaps the -4167 is just there to confuse you.
Simon
|
|
|
|
|
I had written it hence was wondering why. Found it now.
The word "politics" describes the process so well: "Poli" in Latin meaning "many" and "tics" meaning "bloodsucking creatures."
|
|
|
|
|
lets say i have a dll which relies on nhibernate or log4net. And within this dll there're calls which references these external library (nhibernate/log4net .. etc).
To be specific, and as an example I may have a dll (say it will be referenced by a ASPNET app AND a Winform App) and its app.config file look like this:
<configuration>
<configsections>
<sectiongroup name="spring">
<section name="context">
type ="Spring.Context.Support.ContextHandler, Spring.Core"/>
<section name="objects">
type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
</section></section></sectiongroup>
<section name="nhibernate">
type="System.Configuration.NameValueSectionHandler, System,
Version=1.0.5000.0,Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
<section name="log4net">
type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</section></section></configsections>
<spring>
<context><resource uri="config://spring/objects" /></context>
<objects>
</objects>
</spring>
<nhibernate>
... nhibernate config ...
</nhibernate>
<log4net>
... log4net config ...
</log4net>
</configuration>
I want avoid having to copy app.config setting from my DLL when I reference my DLL from a console app this time, then next time to a ASPNET or WebService. Each time having to merge/cut/paste app.config (from Dll) seems like a waste of time.
Thanks
dev
|
|
|
|
|
What you can do is place config sections in a separate config file. Then you can copy the file as a whole rather than copy and paste sections of your app/web.config file.
In your app/web.config file you can refer to the other file like this:
e.g.
<connectionStrings configSource="data.config" />
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
