Best practice to display data received through event from external source.

Hi,

I am receiving objects in form of eventArguments through very frequent
events from some external source. Better to say that we need to handle the
flood of events, and process the object received from each event as soon as
possible and wait for the new events.

Right now I keep on adding the received objects in some Arraylist. I need to
use the saved objects for calculation as well as for displaying on UI. I
have used some of the following techniques to complete the job. Can I get
comments or comparison among the points given below for increasing the
performance. Any further improvements/suggestions are most welcome.

1) Use of the Generic List and Dictionary instead of ArrayList
2) Keep on adding the objects in an arraylist till a certain time limit
(lets say 250 ms) and then forward the ArrayList through event to UI/class
for display/calculation. Since shared arraylist acess can create
issues(for filling data from events and fetching data to send), so I can use
the following alernative methods ...
a) Create 2 Arraylists. Fill first arraylist till a certain time
limit, then set a bool variable and start filling alternate arraylist.
Using the first arraylist for sending event to own UI and
then clear this first arraylist. Next do same thing with alternate arraylist
b) Whenever a time limit elaspes, use lock to access a arraylist
and create clone. Use this clone for sending into the eventarg.
3) Firing so many events can bring down the system. So receive the data
in some event from external source and keep adding into arraylist. External
UI etc can fetch the data after certain interval by accessing a
property wrapped arround a cache.

Regards,
Rajat.

Stoitcho
Fri Sep 22 10:32:15 CDT 2006

Rajat,

Here are my 2 cents:

First I want to say that whatever the case keep in mind that the receivier
and the data processor needs to run in separate threads other wise the
receiver will have to wait for the data processor to finish its work
Further more probably these threads needs to be different than the UI thread
otherwise they will make the UI sluggish. To update the UI in this case will
require marshaling calls to the UI thread which make hurt the performance of
the processing part.

> 1) Use of the Generic List and Dictionary instead of ArrayList

If the objects are struc ( value types ) by all means use generic
collections (or arrays) to save some to boxing/unboxing and copy operations.
If the objects are reference types and you use ArrayList you will need to do
typecasting, but this is not big of a deal I guess, but eys you can avoid
this using generic collection.

> 2) Keep on adding the objects in an arraylist till a certain time
> limit (lets say 250 ms) and then forward the ArrayList through event to
> UI/class for display/calculation. Since shared arraylist acess
> can create issues(for filling data from events and fetching data to send),
> so I can use the following alernative methods ...

Yes using the same array list is probably not the best idea in this case
because you need to have some sync mechanism in place. Unless you don't
implement some kind of partial locking, which is not going to be the easiest
to do you are not going to gain any performance boost since the receiving
part needs to wait for the calculation machanism.
Probably you can lock the collection only for the duration of fetching an
element from the calculation algorithm

> a) Create 2 Arraylists. Fill first arraylist till a certain time
> limit, then set a bool variable and start filling alternate arraylist.
> Using the first arraylist for sending event to own UI and then clear this
> first arraylist. Next do same thing with alternate arraylist

What will hapen if the events comes faster than the calculation algorithm
can process them? In this case you may run in a situation that the second
array is filled out and the first one is not processed yet.

Better you have a queue of collections of data. When the receiving part is
done with this portion of data it adds the prepared collection to tail of
the queue then creates a new one and starts filling it. When the processing
part is done with the current collection it gets a new one by removing it
from the head of the queue and start processing the new one. The old
collections is left for garbage collection. This way you need to lock the
queue only for the duration of the adding and removing.

> b) Whenever a time limit elaspes, use lock to access a arraylist
> and create clone. Use this clone for sending into the eventarg.

This has again problem with the speed of recieving data and processing them.

> 3) Firing so many events can bring down the system. So receive the data
> in some event from external source and keep adding into arraylist.
> External UI etc can fetch the data after certain interval by
> accessing a property wrapped arround a cache.


I don't think you shoud worry about performance of events as long as you
have only one handler.

Whatever the case keep in mind that the receivier and the data processor
needs to run in separate threads other wise the receiver will have to wait
for the data processor to finish its work.

Rajat
Mon Sep 25 04:54:05 CDT 2006

Stoitcho,

Thank you for stepwise response. I need to discuss some of the points, which
you have raised...

1) I have taken the Alternative arraylist, as the time elapses I send the
"Arraylist.Values" in case of alternative arraylist approach. So here values
are being passed in the event rather than the reference . At the calculation
end, I reconstruct the ArrayList (using ICollection interface) and then
perform the calculations. Since calculation algos are working on the copies
of objects, hence even if events come faster, we are safe. In case of clone,
again we have a deep copy, so working on this copy should not interfere with
the original copy's processing(Receiving and adding in collection). Do you
still think that applying the queue here can help us?

2) I agree that we need to shift as much job possible on new thread. Here I
need to tell you that we have wired up the events on a "COM control".
Through these events we are getting the external data. I have dragged the
COM control on the form (Data receiver class). Thus I think, I am bounded to
receive the data on the UI thread. Once I tried to send the exact received
object in a new thread and fetch data in new thread itself, I got garbage
data. Am I thinking here in the right direction?

Regards,
Rajat.

Stoitcho
Mon Sep 25 09:57:49 CDT 2006

Rajat,

> 1) I have taken the Alternative arraylist, as the time elapses I send the
> "Arraylist.Values" in case of alternative arraylist approach. So here
> values are being passed in the event rather than the reference . At the
> calculation end, I reconstruct the ArrayList (using ICollection interface)
> and then perform the calculations. Since calculation algos are working on
> the copies of objects, hence even if events come faster, we are safe. In
> case of clone, again we have a deep copy, so working on this copy should
> not interfere with the original copy's processing(Receiving and adding in
> collection). Do you still think that applying the queue here can help us?

What the queue was trying to solve is scenarios where calculations are
slower than receiving data. What will happen in your alternative array if
the array in the receiving part is filled out ant the processing part is not
done with the old data? If the reveiver keeps adding the objects to the
exisiting array list that will prbably solve the problem but the chunks of
work that the processing part must do next time will be bigger and will keep
growing. However the situations won't be much different with the queue
either - the data still needs to be processed. One advantages of the queue
is the it doesn't need to do deep copies of the objects.


>
> 2) I agree that we need to shift as much job possible on new thread. Here
> I need to tell you that we have wired up the events on a "COM control".
> Through these events we are getting the external data. I have dragged the
> COM control on the form (Data receiver class). Thus I think, I am bounded
> to receive the data on the UI thread. Once I tried to send the exact
> received object in a new thread and fetch data in new thread itself, I got
> garbage data. Am I thinking here in the right direction?

Windows forms uses Single Thread Apartment model, so yes the events will
come in the UI thread. What you can do is to run separate UI thread for the
COM control and receive the data there and then build your multithread
application using proper sync.


--
HTH
Stoitcho Goutsev (100)

Rajat
Tue Sep 26 02:58:41 CDT 2006

Stoitcho,

I got your point. I will check the comparative performance by applying the a
thread safe queue. Also I am looking forward to
receive the data of COM control events on separate thread at my end. If you
have any handy article dealing with the similar
situation (receive the data of COM control events on separate thread),
please share.

Thanks a lot for wonderful suggestions.

Regards,
Rajat.

"Stoitcho Goutsev (100)" <100@100.com> wrote in message
news:uXyPZIL4GHA.4820@TK2MSFTNGP06.phx.gbl...
> Rajat,
>
>> 1) I have taken the Alternative arraylist, as the time elapses I send the
>> "Arraylist.Values" in case of alternative arraylist approach. So here
>> values are being passed in the event rather than the reference . At the
>> calculation end, I reconstruct the ArrayList (using ICollection
>> interface) and then perform the calculations. Since calculation algos
>> are working on the copies of objects, hence even if events come faster,
>> we are safe. In case of clone, again we have a deep copy, so working on
>> this copy should not interfere with the original copy's
>> processing(Receiving and adding in collection). Do you still think that
>> applying the queue here can help us?
>
> What the queue was trying to solve is scenarios where calculations are
> slower than receiving data. What will happen in your alternative array if
> the array in the receiving part is filled out ant the processing part is
> not done with the old data? If the reveiver keeps adding the objects to
> the exisiting array list that will prbably solve the problem but the
> chunks of work that the processing part must do next time will be bigger
> and will keep growing. However the situations won't be much different with
> the queue either - the data still needs to be processed. One advantages of
> the queue is the it doesn't need to do deep copies of the objects.
>
>
>>
>> 2) I agree that we need to shift as much job possible on new thread. Here
>> I need to tell you that we have wired up the events on a "COM control".
>> Through these events we are getting the external data. I have dragged the
>> COM control on the form (Data receiver class). Thus I think, I am bounded
>> to receive the data on the UI thread. Once I tried to send the exact
>> received object in a new thread and fetch data in new thread itself, I
>> got garbage data. Am I thinking here in the right direction?
>
> Windows forms uses Single Thread Apartment model, so yes the events will
> come in the UI thread. What you can do is to run separate UI thread for
> the COM control and receive the data there and then build your multithread
> application using proper sync.
>
>
> --
> HTH
> Stoitcho Goutsev (100)
>

Stoitcho
Tue Sep 26 08:52:16 CDT 2006

Rajat,

I don't have any article, but here you start new UI thread:


Thread t = new Thread( new ThreadStart(ThreadProc));
t.SetApartmentState(ApartmentState.STA);
t.Start();

and the minmum code needed to make a thread to be a UI thread is

void ThreadProc()
{
Application.Run();
}

Depending on the COM object I guess you may need to have a hosting form.
Since win2k there is a support for message-only-windows. Such windows can be
created in WindowsForms using the NativeWindow class, but I don't think this
is going to help in your case. Anyhow if need a form you can create on
hidden form just to host your COM object

void ThreadProc()
{
Form f = new Form();
f.ShowInTaskbar = false;
f.WindowState = FormWindowState.Minimized;
Application.Run(f);
}

Here I use minimized form that doesn't show in the taskbar just because it
is easier than setting the Visible property. When the form starts the
Visible is automatically set to *true* thus simple setting the property
won't work. If you do it in some other place in the form you risk the form
to show-up for a split of a second before disappear. I believe this is
easier to do hidden form.

One more thing... The thread created this way is not a background thread
that is it will keep the application alive unless something kills the
thread. The correct way of doing it is to call the form's Close method.
Other possible solution would be to make the thread a background one, but in
this case it will be kill in a very "brutal" way. The form will be disposed,
but it won't return close notifications.


--
HTH
Stoitcho Goutsev (100)

"Rajat" <rajat.tandon@nirvana-sol.com> wrote in message
news:uxCwaGU4GHA.292@TK2MSFTNGP02.phx.gbl...
> Stoitcho,
>
> I got your point. I will check the comparative performance by applying the
> a thread safe queue. Also I am looking forward to
> receive the data of COM control events on separate thread at my end. If
> you have any handy article dealing with the similar
> situation (receive the data of COM control events on separate thread),
> please share.
>
> Thanks a lot for wonderful suggestions.
>
> Regards,
> Rajat.
>
> "Stoitcho Goutsev (100)" <100@100.com> wrote in message
> news:uXyPZIL4GHA.4820@TK2MSFTNGP06.phx.gbl...
>> Rajat,
>>
>>> 1) I have taken the Alternative arraylist, as the time elapses I send
>>> the "Arraylist.Values" in case of alternative arraylist approach. So
>>> here values are being passed in the event rather than the reference . At
>>> the calculation end, I reconstruct the ArrayList (using ICollection
>>> interface) and then perform the calculations. Since calculation algos
>>> are working on the copies of objects, hence even if events come faster,
>>> we are safe. In case of clone, again we have a deep copy, so working on
>>> this copy should not interfere with the original copy's
>>> processing(Receiving and adding in collection). Do you still think that
>>> applying the queue here can help us?
>>
>> What the queue was trying to solve is scenarios where calculations are
>> slower than receiving data. What will happen in your alternative array if
>> the array in the receiving part is filled out ant the processing part is
>> not done with the old data? If the reveiver keeps adding the objects to
>> the exisiting array list that will prbably solve the problem but the
>> chunks of work that the processing part must do next time will be bigger
>> and will keep growing. However the situations won't be much different
>> with the queue either - the data still needs to be processed. One
>> advantages of the queue is the it doesn't need to do deep copies of the
>> objects.
>>
>>
>>>
>>> 2) I agree that we need to shift as much job possible on new thread.
>>> Here I need to tell you that we have wired up the events on a "COM
>>> control". Through these events we are getting the external data. I have
>>> dragged the COM control on the form (Data receiver class). Thus I think,
>>> I am bounded to receive the data on the UI thread. Once I tried to send
>>> the exact received object in a new thread and fetch data in new thread
>>> itself, I got garbage data. Am I thinking here in the right direction?
>>
>> Windows forms uses Single Thread Apartment model, so yes the events will
>> come in the UI thread. What you can do is to run separate UI thread for
>> the COM control and receive the data there and then build your
>> multithread application using proper sync.
>>
>>
>> --
>> HTH
>> Stoitcho Goutsev (100)
>>
>
>

Rajat
Wed Sep 27 08:33:45 CDT 2006

Right now, I have 2 forms, each hosting a different COM control and getting
the data in form of different events from different servers. I have made the
form classes singleton. These form classes are grouped in a class library
project. I take the instance of these classes and call methods corresponding
to which I start getting data in form of events on the form. So form are not
shown.

Since the instances are made through a GetInstance() method in the same form
class itself, so to apply what you have said, I think I can code this
scenario as ...

TypeName _typeName = null;
public static TypeName GetInstance()
{
if(_typeName == null)
{
Thread t = new Thread( new ThreadStart(ThreadProc));
t.SetApartmentState(ApartmentState.STA);
t.Start();
}

return _typeName;
}

void ThreadProc()
{
f = new _typeName();
Application.Run(f);
}

Is it ok? If Application.Run displays the form then I can definitely use
f.WindowState = FormWindowState.Minimized.

Regards,
Rajat.