|
What's with the thread priority? It doesn't make the thread run any faster. It Just makes the thread run at the expense of not running others system wide.
|
|
|
|
|
So, we're just guessing, instead of looking at the documentation? 
Here's[^] the manual, there's an example at the bottom.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I have a C# and Silverlight project with two combo boxes (CB1, CB2)
-CB1 is initialized and populated with few items.
(e.g. car, plane, motorcycle)
-User selects an item (e.g. car) and CB2 gets automatically populated
(e.g. model, year, color) via the cb1_SelectionChanged()
-user selects the item from CB2 (e.g. model) and a datagid is populated accordingly.
Problem:
Once I selected item from CB2 and datagrid is populated correctly, attempting to select a different item from CB1 generates a "Object reference not set to an instance of an object"
To go around just select a different item then back again to the item and that woks but is really annoying. :)
Any ideas will be greatly appreciated
|
|
|
|
|
Post the piece of code for better understanding...
|
|
|
|
|
Yes, I should have done fist. Thank you
public Home()
{
InitializeComponent();
//initilize the combobox
comboBox1.Items.Add("CAR");
comboBox1.Items.Add("PLANE");
comboBox1.Items.Add("MOTORCYCLE");
for CB1
private void comboBox1_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
string selec = comboBox1.SelectedItem.ToString();
switch (selec)
{
case "CAR":
{
comboBox2.Items.Clear();
label3.Content = "Select cars";
comboBox2.Items.Add("Model");
comboBox2.Items.Add("Color");
}
break;
case "PLANE":
{
comboBox2.Items.Clear();
label3.Content = "Select Site";
comboBox2.Items.Add("model");
comboBox2.Items.Add("EngineType");
comboBox2.Items.Add("choice 1");
comboBox2.Items.Add("choice 2");
}
break;
}//end of switch
}
FOR CB2
private void comboBox2_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
EclipseMTXDomainContext context1 = new EclipseMTXDomainContext(); //load datagrid from database
string selec = comboBox2.SelectedItem.ToString();
switch (selec)
{
case "model":
{
//GET ALL MOdels
dataGrid1.ItemsSource = context1.Protons;
context1.Load(context1.GetProtonsFilteredQuery(1));
}
break;
case "EngineType":
{
//GET ALL Engine Types
dataGrid1.ItemsSource = context1.Protons;
context1.Load(context1.GetProtonsFilteredQuery(1));
}
break;
}//end of switch
}
|
|
|
|
|
picasso2 wrote: string selec = comboBox1.SelectedItem.ToString();
Comboboxes use to send two SelectionChanged events when the user changes the selection: in the first event, the previously selected item is un-selected, at this moment no item is selected, comboBox1.SelectedItem is null, and consequently comboBox1.SelectedItem.ToString(); causes a NullReferenceException.
Then the new item gets selected and SelectedItem has a value again.
Solution: check SelectedItem for null.
|
|
|
|
|
I understand you aren't going to be able to give me a specific answer, but I am kind of stunned at this point...
I work on a library that has competitors. Our APIs are pretty similar. I call MyLibrary.MethodA() 1,000,000 times. It takes 1000ms. I call MyCompetitor.MethodA() 1,000,000 times and it takes 150ms. Both in Debug / Any CPU.
I'm trying to figure out where my overhead is. So in MethodA() I tried returning just null at the beginning. That was already 16ms. MethodA calls an internal method which calls another one, etc. Basically, the only thing I'm doing at the top level methods is checking the params for null. Then I lock a dictionary and do a TryGetValue. At this point I start getting to the method that starts doing real work. I'm already at 195ms and am returning null.
How is that even possible? The other guy is returning 150ms and actually doing the work. I'm at 195ms and returning null from an empty method???
|
|
|
|
|
For other CPians to help and give you useful suggestions, you have to give more context what the method is doing and what algo it is using and does it access the network to access the DBMS? Does it use LINQ? Does it use reflection? Does it use C++/CLI interop? etc...
|
|
|
|
|
Yes, as I said, I haven't gotten to optimizing the algorithm itself yet .
Just calling EMPTY methods in my DLL is slower then calling the other guys FULL method. That's where I'm confused.
His FULL method is 150ms for 1,000,000x.
I'm just calling 4 pretty empty methods. Method1 does nothing but call Method2 (a generic method calling the non generic version). Method2 calls Method3 which just checks that the param is not null and then calls Method4. Method4 locks on a dictionary and calls TryGetValue() (Key = Type, Value = Info class). If it can't find the Info class in the dictionary, it news one up. Now it calls Method5. At this point, I haven't even done the work yet, just getting set up and I'm already at 111ms. The other guy is already done completely at 150ms. That's what I'm puzzled about. Haven't even gotten to any code that I can optimize yet  .
|
|
|
|
|
Have you tried decompile your competitior method with reflector or dotPeek[^] and profile it? Cannot be of any help here. I am more of C++ than C# guy. Here are 2 .NET perf books you can read.
Pro .NET Performance[^]
Writing High-Performance .NET code[^]
I have read the 1st book but not the second because it was just out.
modified 17-Aug-14 22:48pm.
|
|
|
|
|
SV Wong wrote: Have you tried decompile your competitior method
Not a good idea. If this is a commercial product, decompiling it would almost certainly be illegal, even if you didn't use any of the decomipled code.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
SV Wong wrote: Have you tried decompile your competitior method
Really bad idea.
First if you have legal copy of the software it is a possible license violation. Of course if you don't own the code that is a problem itself.
Second if you look at the decompiled code it could subject the code you write to copyright violations or other legal complications.
|
|
|
|
|
He might be caching some data in memory - it could be slower when you call the method only once, but surely speeds up when the method is called a million times.
Are you sure that the competitor's method is thread-safe?
|
|
|
|
|
SledgeHammer01 wrote: Our APIs are pretty similar.
But that has nothing to do with what is happening internally.
|
|
|
|
|
One wonders if this maybe the result of breaking the code into OOP methods instead of one inline bit of spaghetti.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
It does seem like there is quite a bit of overhead in calling methods (when you're calling it 1M x I mean.
|
|
|
|
|
If I understand this correctly, you are calling you method 1 million times and it takes one second. So 1 microsecond to execute. That doesn't sound like a lot to me, but without knowing what it does who knows.
At such speeds, dictionary lookups start to become quite heavy duty operations. I would think locking the dictionary would start to have a bad impact as well (I've got the time 80ns in my head, but that's probably wrong).
Remember that for each look up, the dictionary might call GetHashCode() and Equals() on multiple objects so you need to make sure that your implementations of these things are very efficient.
Bin the dictionary and switch to non-locking synchronization if possible. Also, get Reflector or something on the competitors assembly and see what's happening.
Regards,
Rob Philpott.
|
|
|
|
|
SledgeHammer01 wrote: Then I lock a dictionary and do a TryGetValue.
That might be related to the problem - locking is a notoriously slow operation. You might want to look at using the ConcurrentDictionary class[^] instead.
However, you'll need to profile your code to find out where the bottleneck is. Making random changes in the hopes of improving the performance is never a good idea.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I did switch to ConcurrentDictionary in one area of the code and it shaved some time off @ 1M x.
But it seems, and let me get your thoughts on this, that ConcurrentDictionary is only going to be appropriate in this scenario:
lock (dict)
{
dict.TryGetValue(...);
}
I.e. an atomic operation and not something like:
lock (dict)
{
if (!dict.TryGetValue(...))
{
DoSomeOtherStuff;
DoAFewMoreThings;
NewUpANewObject;
dict.InsertNewObject();
}
}
I.e. a non atomic operation. In the second case, switching to ConcurrentDictionary and not locking would be an issue because you'd have a race condition to insert the new item.
|
|
|
|
|
Your second example should look something like:
theValue = concurrentDict.GetOrAdd(theKey, key =>
{
DoSomeOtherStuff();
DoAFewMoreThings();
var theNewObject = NewUpAnObject(key);
return theNewObject;
});
The entire delegate would be executed within the scope of a lock, as with your non-generic dictionary code. However, the lock would be more granular, based on the number of buckets and the concurrency level of the collection.
If you wanted to execute the "other stuff" outside of the lock, your code would look like:
if (!concurrentDict.TryGetValue(theKey, out theValue))
{
DoSomeOtherStuff();
DoAFewMoreThings();
var theNewObject = NewUpAnObject(theKey);
theValue = concurrentDict.GetOrAdd(theKey, theNewObject);
}
In this case, DoSomeOtherStuff, DoAFewMoreThings and NewUpAnObject would run outside of any lock. However, the insert to the dictionary would not suffer from a race condition, as the class is specifically written to cope with this type of code.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Tricky . I didn't know about that GetOrAdd method. Thanks.
|
|
|
|
|
There are many, many areas that could contribute. Your competitor might delegate all calls to background threads, for instance, giving the appearance that they are processing quickly. They might be using highly optimised native code behind the scenes (after all, just because you've compiled to debug, it doesn't mean your competitor has shipped you a debug version of their code, so you're comparing apples with the Mona Lisa).
|
|
|
|
|
You mean compiling it to x86 or x64 rather then Any CPU? It just seems like I've got overhead calling empty functions. I'm not sure they can kick off background threads as they need to return an object from the method.
|
|
|
|
|
No, I mean that they might be using C++ (for instance). Also, if you compile your code to release version and then compare against theirs, you should get more realistic timings. I guarantee you that their version will be the release version.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
