|
I have some code that I moved into a background thread that takes a considerably longer time to execute then it does if it's done in the main thread.
When in a background thread the code takes 2 minutes to execute. When in the main thread it takes 4 seconds to execute.
This seems like it's way too much of an increase to be normal.
Any ideas of what I can try to bring this execution time closer to 4 seconds while keeping it in a separate thread?
|
|
|
|
|
No idea, but it's almost certainly due to a bug in your code; this would otherwise not happen. Can you post some relevant code snippets?
|
|
|
|
|
Judah Himango wrote: No idea, but it's almost certainly due to a bug in your code; this would otherwise not happen. Can you post some relevant code snippets?
<br />
...<br />
Thread worker = new Thread(new ParameterizedThreadStart(ThreadOperation));<br />
worker.IsBackground = true;<br />
worker.Start(dataobj);<br />
m_dlgThreadProgress.ShowDialog(this);<br />
...<br />
<br />
private void ThreadOperation(object obj)<br />
{<br />
DataObj dataobj = (DataObj)obj;<br />
new ThreadObj(this).TimeConsumingOperation(dataobj);<br />
Invoke(m_delegateCloseProgressDialog);<br />
Invoke(m_delegateListViewUpdate, dataobj);<br />
System.Diagnostics.Debug.WriteLine((DateTime.Now - m_dtStartLoadingTime).ToString());<br />
}<br />
<br />
I pass in "this" to the ThreadObj so it can Invoke operations to update the progress bar dialog. If you need any more code let me know...
|
|
|
|
|
I'm pretty sure this problem is home-grown, something like this doesn't happen regularly.
Perhaps you've introduced the problem with your inter-thread synchonization?
Please post some code, otherwise we won't be able to help you.
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
mav.northwind wrote: I'm pretty sure this problem is home-grown, something like this doesn't happen regularly.
Perhaps you've introduced the problem with your inter-thread synchonization?
Please post some code, otherwise we won't be able to help you.
See code in my reply above, but I also tried using a BackgroundWorker instead of a Thread and I'm seeing the same result...
<br />
...<br />
m_bwWorker.RunWorkerAsync(dataobj);<br />
<br />
private void m_bwWorker_DoWork(object sender, DoWorkEventArgs e)<br />
{<br />
ThreadOperation((DataObj)e.Argument);<br />
}<br />
<br />
private void ThreadOperation(object obj)<br />
{<br />
DataObj dataobj = (DataObj)obj;<br />
new ThreadObj(this).TimeConsumingOperation(dataobj);<br />
Invoke(m_delegateCloseProgressDialog);<br />
Invoke(m_delegateListViewUpdate, dataobj);<br />
System.Diagnostics.Debug.WriteLine((DateTime.Now - m_dtStartLoadingTime).ToString());<br />
}<br />
|
|
|
|
|
What happens if you do BeginInvoke instead of Invoke?
Also, when you used a background worker, you used ReportProgress instead of Invoke, right? (With BackgroundWorker, you ReportProgress which gets executed on the UI thread asychronously.)
|
|
|
|
|
Judah Himango wrote: What happens if you do BeginInvoke instead of Invoke?
Also, when you used a background worker, you used ReportProgress instead of Invoke, right? (With BackgroundWorker, you ReportProgress which gets executed on the UI thread asychronously.)
I changed all my Invokes to BeginInvoke in the LongOperation and outside of it with no change in execution speed.
|
|
|
|
|
What happens if you remove all Invoke and BeginInvoke calls?
|
|
|
|
|
Judah Himango wrote: What happens if you remove all Invoke and BeginInvoke calls?
Same thing, if it's called from within a worker thread it's quite a bit slower. I've even done some more timings where i take out the long process out of the method that takes too much time and there is still a noticable difference between threaded and non-threaded.
|
|
|
|
|
How much slower are we talking here?
Keep in mind, multithreading does not make your application any faster on single-CPU machines. In fact, due to context switching, using multiple threads is actually slower than using a single thread on single-CPU machines.
So with that in mind, of course running on a background thread is going to take longer. What's more is, if your main UI thread is busy and you've got only 1 CPU, then your CPU is going to be constantly doing context switches to execute pieces of each thread, which is going to slow down the overall background process. If you've got a dual core machine or better, this wouldn't apply.
But you shouldn't be seeing huge differences even on single-CPU machines; only minor differences. If you're seeing huge differences, then something in your code is wrong (lock problems? sharing data between threads?), but it's impossible to tell without seeing what all the code is doing.
If all else fails, run a performance profiler on your code and see what's taking time. I use Ants Profiler which gives per-line timings and shows you your slowest methods. This should help diagnose what's taking long, which will help you figure out why it's taking longer on a background thread.
|
|
|
|
|
I ran the Ants profiler and it takes 90 seconds within the background thread and less then 1 second if it's in the main thread. This seems excessive to me to be just single CPU related but it may be, considering every line of code is being executed an equal number of times regardless which thread executes it. I'll have to run it on my dual core processor tonight and see if the results are better.
|
|
|
|
|
an 89 second difference tells me that certainly something is wrong in your code. What lines of code are taking longer? What are those lines doing?
|
|
|
|
|
I have a foreach loop that does a number of string comparisons, contains, and removes whitespace.
I tried running it on a dual core processor and there was no change.
|
|
|
|
|
Is it possible to post your project? I'm pretty sure I could fix it if I've got it here sitting in front of me.
When you run it under the performance profiler, which lines are taking longer? Surely the string comparison and manipulation isn't taking longer on a background thread?
|
|
|
|
|
Judah Himango wrote: Is it possible to post your project? I'm pretty sure I could fix it if I've got it here sitting in front of me.
When you run it under the performance profiler, which lines are taking longer? Surely the string comparison and manipulation isn't taking longer on a background thread?
Unfortunately I'm not able to send my project. But I did look at the profiler a little more and can give you some more information on the lines of code that seem to be causing the slowdown.
The dataobject that I pass into the method that takes a long time has a few properties that are List<htmlelement>. I loop through all these and analyze the individual HtmlElements contained within the list.
When I do the following:
<br />
string href = link.GetAttribute("href");<br />
*where link is an HtmlElement that is contained in the list that's a property of the passed in DataObject
or
<br />
if((currentelement.Name == destination &&<br />
currentelement.TagName.ToUpper() == "A") ||<br />
currentelement.Id == destination)<br />
*where currentelement is an HtmlElement that is contained in the list that's a property of the passed in DataObject
When I access the properties of the HtmlElement within the background thread is when the excessive execution takes place. This may have to do with HtmlElement actually being a COM object with the .NET wrapper around it?
Hopefully this gives you some more info  I appreciate your time looking into this.
|
|
|
|
|
Yes; since HtmlElement is actually part of a windows forms control, you may not want to access that on a background thread. Also, since the background thread is most likely MTA thread apartment, COM is probably wailing loudly at all this.
Instead of passing a list of System.Windows.Forms.HtmlElement to the background thread, can you pass a copy of only the data you need? For instance, from your snippet it appears you need the href, Name, TagName, and Id of every HtmlElement. So instead of pulling those from the MTA background thread, could you pull them from the UI thread, then pass those strings off to the background worker (perhaps contained in a custom HtmlElementInfo class or something)?
p.s. ToUpper() always allocates a new string. Perhaps you could use this instead:
string.Equals(currentElement.TagName, "A", StringComparison.InvariantCultureIgnoreCase)
|
|
|
|
|
I actually just started to make my own HtmlElement class which only contains the info I need. I think this will solve the problem. Thanks again
|
|
|
|
|
Hello,
I have the following code:
strCmd = "UPDATE [TBl] SET [text] = " + htmldoc + " where id = 11";<br />
OleDbCommand cmd2 = new OleDbCommand(strCmd, conn);<br />
cmd2.ExecuteNonQuery();
Where "htmldoc" is a variable that contains the content of a big html file with lot of quotes extra... so when I execute the code I'm getting an error.
How can I fix that?
Thanks in advance.
|
|
|
|
|
That is not the problem. Quotation marks has no special meaning at all in a string in SQL. The problem is that you forgot the apostrophes around the string.
There are other characters that you should encode, though, as they may appear in the html code. You should encode apostrophes, and if you are using an MySQL database you should also encode backslashes.
---
b { font-weight: normal; }
|
|
|
|
|
Hi
Your problem is, quite possibly, the fact you're using concatenated command text. If the HTML document contains any apostrophe characters, the command will fail. Even worse, if the HTML document contained specially crafted SQL commands, your whole database could be wiped out or an attacker could read your entire database freely. This security risk and bug in your code is known as SQL injection.
Here's how to fix the problem and remove the security risk:
strCmd = "UPDATE [TBl] SET [text] = @HtmlInput where id = 11";
OleDbCommand cmd2 = new OleDbCommand(strCmd, conn);
OleDbParameter htmlParameter = new OleDbParameter("@HtmlInput", htmlDoc);
cmd2.Parameters.Add(htmlParameter);
cmd2.ExecuteNonQuery();
Note that this assumes htmlDoc variable to be of type string.
p.s. next time use <pre> tags to surround your code snippets.
|
|
|
|
|
Hi!
It's embarrasing to ask such a simple question, but is there a simple way to find out how much a NumericUpDown control changed on a ValueChanged event? I know it can be worked around, but I first want to check so that I don't do a lot of extra work.
Regards,
Martin
|
|
|
|
|
Nope, the ValueChanged event does not send the old value, sorry. 
Obviously this could be done via a workaround by storing the current value every time the ValueChanged event occurs. You can then compare that against the current value the next time the ValueChanged event occurs.
|
|
|
|
|
The problem is that I have a lot of spinners, and I don't think it's very efficient to create a variable for every single one of them...
|
|
|
|
|
You'd be storing an integer variable for each of them. Unless you have thousands of numeric up down controls, the performance hit would be negligible.
|
|
|
|
|
hi ..
this is my code to set ImageIndex of my button :
ImageList list = new ImageList();
System.Drawing.Icon _icon = new Icon("PRINTERS11.ico");
list.Images.Add(_icon);
button1.ImageList = list;
button1.ImageIndex = 0;
but my Icon is very small in button and i can not resize :
button1.ImageList.Images[0].Size
because it's readonly . How to set size of My icon in button ??
thanks
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
