|
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" />
|
|
|
|
|
|
|
|
|
amardeep deshmukh wrote: I will display all the versions of application installed on the clients machine- By looking in the Registry
How do you find the application from the registry? Do you use HKEY_CLASSES_ROOT?
|
|
|
|
|
|
Now we are a bit off from my area, but if you know either CLSID or ProgId, there are functions for COM like ProgIDFromCLSID and CLSIDFromProgID. However, I don't know if they work for the guid in Uninstall-path. I've understood that for example Microsoft Office is just one entry in Uninstall but it has several com components for all products (word, excel etc).
AFAIK installer keeps it's own inventory under HKEY_CLASSES_ROOT\Installer\Products. Also all CLSID's are under HKEY_CLASSES_ROOT\ClSID. In products folder most products have Transforms entry and the guid in that seem to reference to the installation folder in SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.
That's about all I could come up with.
|
|
|
|
|
|
amardeep deshmukh wrote: I got the workaround to this problem
Very good
|
|
|
|