Hi all, I hope someone can help.

I'm trying to read 27,000 records from a database at application start
up. This of course made the loading time really slow. So I used the
ThreadPool.QueueUserWorkItem and have the load taking place on that
background thread. Even with this background thread, the UI becomes
slow and unresponsive. Am I missing something here?

I'm using the MVC design pattern, so in the form constructor I
instantiate a Controller object. The Controller is what makes a call
a method I wrote Catalog.BeginLoad().

Catalog.BeginLoad()
ThreadPool.QueueUserWorkItem(new WaitCallback(getCatalog), new
object[] { _customerID, _callbackDelegate });

The getCatalog method unwraps the Object parameter of the WaitCallback
delegate and calls GetCatalog (The synchronous version of the code).

In the GetCatalog method I have a SqlCeDataReader that opens the table
and loops through the 27,000 records and turns them into an "in
memory" object representation of the Catalog.

I understand the reading from SQL CE will be slow, but I figured on a
background thread this would not affect the UI.

Any thoughts?

Thanks in advance.
-Rob-

First, I wouldn't use a ThreadPool thread for this - that's a long
operation. Second, if you put in a yield (Thread.Sleep(0) in the processing
thread, or better yet lower its priority, does that improve things? My bet
is that you're just having contention over processor time and the UI is
paying the price.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com


"RobRasti" <rasta475 (AT) gmail (DOT) com> wrote

Chris,

Thank you for the reply. I had actually thought of the Thread.Sleep
idea. I put in a small one (10 milliseconds) and that had no effect.
I will rework this to use a Thread and set a lower priority. I did
notice both threads in the VS 2008 debugger were at "Normal"
priority. Is there a restriction or performance hit when using the
ThreadPool compared to using a Thread?

I'm fairly new to threading within the compact framework, so I
appreciate the help. The only reason I am trying this now is because
of the immense performance gains I saw when simply moving a File IO
process to a background thread on my desktop. I assume the
performance gains will not be anywhere near the same, but I'd imaging
it shouldn't cause the UI freezes I'm seeing now.

Again thank you for your help.

-Rob-

If yielding for 10ms didn't fix it (which is way drastic) then there's
something else going on eating scheduler quantum. There's no reason, based
on what you've told us, the device shouldn't be able to keep up with what
you're doing.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com



"RobRasti" <rasta475 (AT) gmail (DOT) com> wrote

I've no solution for your problem. I just want to say that we are faced with
very similar issues...

We're using the MVC pattern, too. The view encapsulates a form running in
it's own GUI thread with it's own message loop. The controller is running in
another thread. The controller controls another component that permanently
polls a smart card reader connected by a serial port. As soon as a smart
card is discovered, the controller receives a notification and starts the
smart card validation procedure. After validation has been finished, the
view gets a notification and shows the validation result.

The system load has been measured countless times with different tools and
seldom exceeds 10%. Nevertheless, the UI is very sluggish. It takes a few
seconds before a button click fires the Click event! We also fiddled around
with thread priorities and also inserted waits into the smart card reader
polling loop. Alas, that lead to nowhere.

We have different device types: one with PXA255 running @400 MHz and CE 5.0
and one with PXA320 running @624 MHz and CE 6.0. Paradoxically, the
described problem only exists on the fast device with CE 6.0.

Is your device running CE 6?

-peter

You also shouldn't have any problem. I'm doing similar things on CE 6.0
devices without any problem. There's got to be something going on that's
stealing quantum. Kernel Tracker would tell you exactly what.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"Peter Schottland" <peter (AT) schottland (DOT) com> wrote

I created a Thread object instead of using the ThreadPool and set the
Priority of the Thread to BelowNormal. This freed up the UI and is
now behaving as expected. Turned out I forgot another basic step when
using SQL CE and large volumes of data; Indexes. I indexed the tables
and now my app is running extremely well.

Thank you for your help.

Sounds good.

Do I need a debug OS image in order to run the Kernel Tracker?

-peter

No, you can run kernel tracker on any image (that has it enabled anyway, but
all of them I've seen do).


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Giving back to the embedded community
http://community.OpenNETCF.com

"Peter Schottland" <peter (AT) schottland (DOT) com> wrote

Chris Tacke, MVP wrote:
I do that? I work with large DB's. Although I have not encountered the
problems that have been discussed, I would like to know how to try and
solve a future problem.

Thanks

TMA